Update: note that the currently accepted answer perpetuates a common misunderstanding about the behaviour of git push
, which hasn't been corrected despite a comment pointing it out.
Your summary of what remotes are - like a nickname for the URL of a repository - is correct.
So why does the URL not git://[email protected]/peter/first_app.git but in the other syntax -- what syntax is it? Why must it end with .git? I tried not using .git at the end and it works too. If not .git, what else can it be? The git at the beginner seems to be a user account on the git server?
The two URLs that you've mentioned indicate that two different transport protocols should be used. The one beginning with git://
is for the git protocol, which is usually only used for read-only access to repositories. The other one, [email protected]:peter/first_app.git
, is one of the different ways of specifying access to a repository over SSH - this is the "scp-style syntax" described in the documentation. That the username in the scp-style syntax is git
is because of the way that GitHub deals with identifying users - essentially that username is ignored, and the user is identified based on the SSH key-pair that they used to authenticate.
As for the verbosity of git push origin master
, you've noticed that after the first push, you can then just do git push
. This is because of a series of difficult-to-remember-but-generally-helpful defaults :)
remote.master.url
in your case) is used. If that's not set up, then origin
is used.master
, master:my-experiment
, etc.) specified, then git defaults to pushing every local branch that has the same name as a branch on the remote. If you just have a branch called master
in common between your repository and the remote one, that'll be the same as pushing your master
to the remote master
.Personally, since I tend to have many topic branches (and often several remotes) I always use the form:
git push origin master
... to avoid accidentally pushing other branches.
In reply to your comments on one of the other answers, it sounds to me as if are learning about git in a top-down way very effectively - you've discovered that the defaults work, and your question is asking about why ;) To be more serious, git can be used essentially as simply as SVN, but knowing a bit about remotes and branches means you can use it much more flexibily and this can really change the way you work for the better. Your remark about a semester course makes me think of something Scott Chacon said in a podcast interview - students are taught about all kinds of basic tools in computer science and software engineering, but very rarely version control. Distributed version control systems such as git and Mercurial are now so important, and so flexible, that it would be worth teaching courses on them to give people a good grounding.
My view is that with git
, this learning curve is absolutely worth it - working with lots of topic branches, merging them easily, and pushing and pulling them about between different repositories is fantastically useful once you become confident with the system. It's just unfortunate that: