Github recommends the foolowing URL for setting a remote repo https://github.com/{USERNAME}/{PROJECTNAME}.git [When creating a new repo on Github].
But only when a different format - https://{USERNAME}@github.com/{USERNAME}/{PROJECTNAME}.git - I was able to work with a second account on the same git client [https://stackoverflow.com/a/27407168/7224430].
{USERNAME}@ in front of github.com have?It affects which cached password will be used.
An HTTPS URL can trigger credentials caching if your git cconfig credential.helper is set to manager-core
Adding username@ in your URL forces the helper to use the right username, helping it to retrieve the right password.
Wouldn't it make sense to use this URL format by default
Only if you have several accounts.
If not, it does not add much.
If you're trying to clone a repo without logging in, the below will prompt you for a password
git clone https://username@github.com/username/repository.git
If you check your gitconfig file, programfiles->git->etc->gitconfig
You could notice the credential helper set to manager-core
You can be accessing/cloning multiple GitHub accounts from your local. Using a username lets it use/cache the respective account credentials.
In CI/CD pipelines when we configure the first step where the code gets checked out from the remote repository, we have username and password picked from the credential manager/helper
git pull https://${GIT_USERNAME}:${GIT_PASSWORD}@github.myorg.com/myrepo.git
More or less, this is what happens in our system locally, where the credentials are picked from the cache based on the username.
In the case of ssh, when you specify git@github.com:username/repo.git, it simply tells git that the user is git itself and that it should go get the credentials (public key) from the ssh-agent for the host github.com.
You could also set the username for a specific host
[credential "https://example.com"]
username = foo
Ref:- http://git-scm.com/docs/gitcredentials
Ref:- https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage
Perhaps you've noticed that sometimes git asks you for the password, that can be triggered either due to SSH key being encrypted or because of the HTTP protocol getting an unsuccessful response.
By issuing https://{USERNAME}@something you are actually complying with the protocol's shape for providing credentials(URL anatomy). In full it'd be:
protocol://username:password@domain:port/path?query=value&query2=value2#anchor
Therefore if you'd want, you could have provided a password even with a plaintext (and have it logged in a console history, which is not recommended).
The HTTP credentials are most likely triggered by one of these statuses:
which git checks and based on the *-Authenticate header then sends back to the git server when using HTTP protocol.
When not providing the credentials via URL git has to find another way to provide them (if required) e.g. by already mentioned credential helper.