In my last post, I discussed the basics of using git with a central repository, doing the sorts of things that we do in Gnome. There were some very helpful comments, and I’d like to share some of that information for the benefit of everybody else.
Branching
My instructions for creating and working on a local branch went like this:
git branch whizbang-feature master
git checkout whizbang-feature
Behdad pointed out that you can use the -b argument with git checkout to create a branch and check it out, all in one command. So those two commands become
git checkout -b whizbang-feature master
Of course, as with git branch, if you omit the last argument, it defaults to branching from whatever you currently have checked out.
Updating
My instructions for getting updates from the server were
git pull origin
Behdad, Marko, and daniel all pointed out that this isn’t optimal. You very likely have changes in your local repository. What you want is to get the remote changes and merge your local changes on top, as if they were developed from the now-current remote repository all along.
git fetch
This fetches the changes from the remote repository and puts them in your local repository. They are not merged in with your local checkout, just the local repository that’s sitting in .git.
It should be pointed out that git pull is basically just a shortcut for git fetch && git merge. But git merge attempts to merge the two development histories (remote updates and local changes) together, rather than just sticking your local changes on the end. So instead of git merge, we’ll call
git rebase origin/master
The git-rebase(1) man page has a nice ASCII diagram to help you visualize what’s happening.
bzr deals with branches much more intuitively: a branch is a directory, period. When you look at a bzr tree you know it does not contain hidden branches. It’s just like something I liked when switching from CVS to Subversion, that branches suddenly became less “magical” and been given a more physical appearance. bzr picked up the branch-is-directory concept very nicely, while git decided to go for hidden branches.
Now, of course that if you want to have multiple branches and save some disk space, bzr supports it as well. You create a “repository”, which is just a parent directory, with all branches of the same project as subdirectories of the repository. Then automatically bzr saves space by only saving the differences between different branches.
Not that I hate git, but bzr is just much better usability wise.
i’m sure git-rebase is useful, but i don’t think it should be always used.
imho it’s much better, that when you start to work on a feature, then you create a branch, and work (commit) in that branch. when finish the feature, and only then, only when all your commits are done, start to worry about how to merge this branch back into the main branch.
and when you are merging it back, you can do it either by rebasing, or by simply merging it.
i think there is a key difference between svn/cvs and git/hg/bzr:
in svn/cvs, you usually update before you commit
in git/hg/bzr, you just commit everything you need, and then at the end (after all the commits are done), you merge your work into the main branch.
so maybe for someone coming from svn/cvs, the rebase-frequently approach seems more familiar.
git-rebase is nice if you want to have a linear history. but if you don’t care about linear history, i don’t see any reason to use it.
(of course, this all is about the case when you work on a project whose main branch is also in git. if you are trying to commit your changes to svn using git, then you must rebase)
Gustavo, I think you just sold me on git. I absolutely hate that branches and tags in SVN are just directories. In my first git blog post, I said that I actually like CVS more than SVN. That’s why. I can’t tell you how many things I’ve run across that are harder (or even impossible) because SVN doesn’t have real branches and tags.
Gábor, I see your point. I was just passng along what the majority of commentors seemed to think was a good idea. I think I’d need time with a larger project with more developers before I could decide what I like more.