James Bowes

Purveyor of Pre-eminent Programmes

git rebase: keeping your branches current

with 7 comments

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.


Written by jbowes

January 26, 2007 at 7:29 pm

Posted in SCM, tech

7 Responses

Subscribe to comments with RSS.

  1. […] must be obvious from previous posts that I love git. Tonight I sent a patch to the mailing list. It’s small and simple; it […]

  2. […] commits, I did an ‘hg pull’ and ‘hg merge’. Since I did not have ‘git rebase‘ available, I now have the merged code right in the middle of my commits. If all of my […]

  3. […] switch to master, do a pull, switch to a branch I’d like to work on and then do a rebase (see here for a nice explanation) in this branch, so that it’s in sync with the Sourceforge […]

  4. […] Git Gets Demystified and Subversion Control some more links for reading: The Git Parable git rebase: keeping your branches current James Bowes i also want to get comfortable with git since its getting hot these […]

  5. Question… shouldn’t the last diagram be:

    upstream ==========A==========A’

    you +=====A’b

    Or am I misunderstanding rebase (I’ve been using git for a while but only used merge… I’m trying to understand the differences and values of rebase)


    Dan Sharp

    November 26, 2009 at 9:40 am

    • Hi Dan:

      Yeah, you’re right. I’ve updated the post. Thanks!


      November 26, 2009 at 10:28 am

  6. […] “forward-port local commits to the updated upstream head”. Hmm. Thankfully James Bowes posted a solid explanation of the basic […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: