Comments on: When is git rebase better than git merge?

By: ripper234

ripper234 — Wed, 17 Aug 2011 04:51:33 +0000

@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.

By: wcoenen

wcoenen — Tue, 16 Aug 2011 21:22:41 +0000

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.

By: Ken Egozi

Ken Egozi — Tue, 14 Jun 2011 21:28:21 +0000