This blog has moved to Medium

Subscribe via email


«
»

When is git rebase better than git merge?

14/6/11, 22:57
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

In Ken’s “git for gits” presentation today, I asked when is “git rebase” better than “git merge”.
I want to summarize what I think the best answer is in this post (hint: it’s not “the version tree looks simpler after a rebase”).
If I recall correctly most of the content of this post appears in some form in the Git Book, but there’s no harm in retelling it in my own words.

Suppose you’re working on a private feature branch, and master is receiving some commits as well.
If you try to merge master to your feature branch, you have to resolve all the conflicts at once. If you have a lot of them, this can be painful.

When you rebase, you are effectively reapplying your work, commit by commit, on top of the work done on master. At any point in this process, if there are conflict, you can resolve only that conflict, compile and test your work, and once you’re satisfied proceed to the next conflict. This can be indispensible when trying to do large merges (I’ve had merges that take a few hours to resolve and test … I still remember telling everyone “please don’t commit to trunk for the next few hours, I have a huge merge).

The downside is of course that you’re altering history, and if someone else cloned your repository this might mess up their work – so only do this on private branches.

Tags: ,

3 Comments

  2. wcoenen:

    Uh? If I understand correctly, you can do exactly the same thing with merges. You can take the first commit of your private branch, merge it with master, resolve conflicts, compile, test, merge the second commit, etcetera.
    It seems to me that rebase is just a slightly improved “svn update”. If you are going the DVCS route, it’s better to just embrace merging.

    17/8/11, 0:22

  3. ripper234:

    @wcoenen – my example is in fact about merging master into a private branch. You can’t do that incrementally – just think about it.

    (Perhaps what got you confused is my off topic tale of telling people not to commit to trunk – it’s not really relevant since I’m merging/rebasing the work trunk to my branch).

    I admit I don’t have much experience in working in a pure git environment yet, but I think that rebasing is often a better way to go than merging in this context. The easiest way to deal with the fact people develop on master while you’re working on a private branch is to play “what if I had only started my work today, after all new commits went into master” – this is what rebase does.

    17/8/11, 7:51