git rebase: keeping your branches current

update: This post is now on my new blog.

Where possible, I use git for my scm now. All software on dangerously incompetent is stored in git, and I do my personal yum work with git-cvsimport. One of the reasons I like git so much is git-rebase. Here’s an example of how it works:

There is some upstream project that you wish to work on. You clone this upstream project when it is in state A, and make some changes. Your personal branch is now in state Ab, that is, A plus some set of changes b.

upstream ==========A

you                +=====Ab

Now, while you’ve been writing b, more changes have occurred upstream. These changes may or may not also be contained in b. Upstream is now in state A’

upstream ==========A==========A'

you                +=====Ab

Now, how do you get the differences between A and A’ into your branch? With many distributed scms, you would perform a merge. The merge will take the differences between A and A’ and apply them on top of Ab (this is a greatly simplified explaination, of course). Over time, you end up with a history in your branch that interleaves changes from upstream with your own changes. Merge is an option with git, but you can also perform a rebase.

With a rebase, the changes between A and Ab are taken and reapplied at A’:

upstream ==========A==========A'

you                           +=====A'b

So your own changes are always the most recent. In practice, I find this to be a very elegant approach. git-rebase makes it easy to see and manipulate your own set of changes against the upstream codebase.