What is "git remote add ..." and "git push origin master"?

Quite often, Git and Ruby on Rails looks like magic... such as in the first chapter of Ruby on Rails 3 Tutorial book, it talks about Git:

git remote add origin git@github.com:peter/first_app.git
git push origin master

And it pretty much says "it just works" without saying too much about what they are and start talking about branching. Searching on the Internet shows that git r开发者_开发问答emote add is to add a "short name", such as origin, and it can be any name as well, which is like an alias to a URL.

And origin is the usual path of where the remote repository points to (in http://git-scm.com/book/en/Git-Basics-Working-with-Remotes under "Adding Remote Repositories").

So why is the URL not git://git@github.com/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 in git@github.com seems to be a user account on the Git server?

Also, why does it need to be so verbose to use git push origin master? Can't the default be origin and master? I found that the first time, the origin master is needed, but after a small edit and commit, then git push is all it needs (no need origin master). Can somebody who knows what is going on give some details?

Sometimes it feels like a lot of magic without explanation... and sometimes the person using it is so confident and when asked why, can't explain it, and respond with something like "that's the way it is". Sometimes very practical and pragmatic. It is not bad to be practical, but probably not practical to the point to not know what is going on.

Git is like Unix. It is user-friendly, but it is picky about its friends. It's about as powerful and as user-friendly as a shell pipeline.

That being said, once you understand its paradigms and concepts, it has the same Zenlike clarity that I've come to expect from Unix command-line tools. You should consider taking some time off to read one of the many good Git tutorials available online. The Pro Git book is a good place to start.

To answer your first question.

1. What is git remote add ...?

   As you probably know, Git is a distributed version control system. Most operations are done locally. To communicate with the outside world, Git uses what are called "remotes". These are repositories other than the one on your local disk which you can push your changes into (so that other people can see them) or pull from (so that you can get others changes). The command git remote add origin git@github.com:peter/first_app.git creates a new remote called origin located at git@github.com:peter/first_app.git. Once you do this, in your push commands, you can push to origin instead of typing out the whole URL.

2. What is git push origin master?

   This is a command that says "push the commits in the local branch named master to the remote named origin". Once this is executed, all the stuff that you last synchronised with origin will be sent to the remote repository and other people will be able to see them there.

Now about transports (i.e., what git://) means. Remote repository URLs can be of many types (file://, https://, etc.). Git simply relies on the authentication mechanism provided by the transport to take care of permissions and stuff. This means that for file:// URLs, it will be Unix file permissions, etc. The git:// scheme is asking Git to use its own internal transport protocol, which is optimised for sending Git changesets around. As for the exact URL, it's the way it is because of the way GitHub has set up its Git server.

Now the verbosity. The command you've typed is the general one. It's possible to tell Git something like "the branch called master over here is local mirror of the branch called foo on the remote called bar". In Git speak, this means that master tracks bar/foo. When you clone for the first time, you will get a branch called master and a remote called origin (where you cloned from) with the local master set to track the master on origin.

Once this is set up, you can simply say git push and it'll do it. The longer command is available in case you need it (e.g., git push might push to the official public repository and git push review master can be used to push to a separate remote which your team uses to review code). You can set your branch to be a tracking branch using the --set-upstream option of the git branch command.

I've felt that Git (unlike most other applications I've used) is better understood from the inside out. Once you understand how data is stored and maintained inside the repository, the commands and what they do become crystal clear. I do agree with you that there's some elitism amongst many Git users, but I also found that with Unix users once upon a time, and it was worth ploughing past them to learn the system. Good luck!

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://git@github.com/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, git@github.com: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 :)

• If no remote is specified, the remote configured for the current branch (in remote.master.url in your case) is used. If that's not set up, then origin is used.
• If there's no "refspec" (e.g. 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 flexibly 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:

• The primary documentation for Git is so hard to parse for newcomers. (Although I'd argue that if you google for almost any Git question, helpful tutorial material (or Stack Overflow answers :)) come up nowadays.)
• There are a few odd behaviours in Git that are hard to change now because many scripts may rely on them, but are confusing to people.

Have a look at the syntax for adding a remote repository.

git remote add origin <url_of_remote repository>

Example:

git remote add origin git@github.com:peter/first_app.git

Let us dissect the command:

git remote this is used to manage your central servers for hosting your Git repositories.

Maybe you are using GitHub for your central repository stuff. I will give you a example and explain the git remote add origin command

Suppose I am working with GitHub and Bitbucket for the central servers for the Git repositories and have created repositories on both the websites for my first-app project.

Now if I want to push my changes to both these Git servers then I will need to tell Git how to reach these central repositories. So I will have to add these,

For GitHub

git remote add gh_origin https://github.com/user/first-app-git.git

And For Bitbucket

git remote add bb_origin https://user@bitbucket.org/user/first-app-git.git

I have used two variables (as far it is easy for me to call them variables) gh_origin (gh for GitHub) and bb_origin (bb for Bitbucket) just to explain you we can call origin anything we want.

Now after making some changes I will have to send (push) all these changes to central repositories so that other users can see these changes. So I call

Pushing to GitHub

git push gh_origin master

Pushing to Bitbucket

git push bb_origin master

gh_origin is holding value of https://github.com/user/first-app-git.git and bb_origin is holding value of https://user@bitbucket.org/user/first-app-git.git

This two variables are making my life easier

as whenever I need to send my code changes I need to use this words instead of remembering or typing the URL for the same.

Most of the times you won't see anything except than origin as most of the times you will deal with only one central repository like GitHub or Bitbucket for example.

1. The .git at the end of the repository name is just a convention. Typically, on Git servers, repositories are kept in directories named project.git. The Git client and protocol honours this convention by testing for project.git when only project is specified.

2. git://git@github.com/peter/first_app.git is not a valid Git URL. Git repositories can be identified and accessed via various URL schemes specified here. git@github.com:peter/first_app.git is the ssh URL mentioned on that page.

3. Git is flexible. It allows you to track your local branch against almost any branch of any repository. While master (your local default branch) tracking origin/master (the remote default branch) is a popular situation, it is not universal. Many a times you may not want to do that. This is why the first git push is so verbose. It tells Git what to do with the local master branch when you do a git pull or a git push.

4. The default for git push and git pull is to work with the current branch's remote. This is a better default than origin master. The way git push determines this is explained here.

git is fairly elegant and comprehensible, but there is a learning curve to walk through.

This is an answer to this question (Export Heroku App to a new GitHub repo) which has been marked as duplicate of this one and redirected here.

I wanted to mirror my repository from Heroku to GitHub personal so that it shows all commits, etc., which I also made in Heroku. Importing a Git repository using the command line in the GitHub documentation was useful.

Git remote add origin:

It centralises your source code to the other projects. It is developed based on Linux, complete open source and make your code useful to the other git users. We call it as reference.

It pushes your code into the Git repository using remote URL of GitHub.