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.
