Posted By: Anonymous
Quite often, Git and Rails looks like magic… such as in the first chapter of Rails 3 Tutorial book, it talks about Git:
git remote add origin [email protected]: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 net shows that
git remote 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 repo 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://[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
[email protected] 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. User friendly but 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.
git remote add ...
As you probably know,
gitis a distributed version control system. Most operations are done locally. To communicate with the outside world,
gituses what are called
remotes. These are repositories other than the one on your local disk which you can
pushyour changes into (so that other people can see them) or
pullfrom (so that you can get others changes). The command
git remote add origin [email protected]:peter/first_app.gitcreates a new remote called
[email protected]:peter/first_app.git. Once you do this, in your push commands, you can push to
origininstead of typing out the whole URL.
git push origin master
This is a command that says "push the commits in the local branch named
masterto 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 (
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
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
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 repo 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 apps 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!