small medium large xlarge

29 Dec 2008, 00:05
Ben Kimball (1 post)

I’m very unclear on the difference between rebase and merge, and after reading the book and looking at the man pages I’m even more confused.

First, the book seems to disagree with the git-rebase man page about what rebase does to a repository. On pages 34-35, figures 3.1 and 3.2 show that a rebase operation takes two branches and — I have to say it — merges them into one, interleaving commits. However, the “man page”: has a diagram that appears to append commits.

Second, after reading “this page”: (“Rebase Considered Harmful”) I’m puzzled: why does chapter 3 use rebase at all, as opposed to merge? Isn’t merging really what we’re after in this situation?

All I know about version control I learned from svn, which is probably why I’m so baffled. Please forgive (and point out) any bad assumptions I’ve made. :)

Thanks! Ben

19 Jan 2009, 20:34
Pieter (4 posts)

After reading the book I’ve got the same question. Could someone elaborate on this?



23 Jan 2009, 02:35
Travis Swicegood (56 posts)

Hey guys;

@Ben: about the diagrams. The man page you linked to and the diagrams on 34 and 35 both have the same intent, but I could make it a little more clear. My intent is to show that when the history is now one path. I’m making a note that I could make that more clear, though.

As for rebase vs. merge, Ben, you are correct, a merge would have achieved a similar goal without changing the commit name for the commit on @master@. I chose to use @git rebase@ here instead of merging, however, to show off one of the more useful features of having a private repository—the ability to rewrite the history.

You do bring up an excellent point, though. I’m going to make a note that I should clarify that point down the road if we do a 2nd edition.

Thanks for your feedback! I hope you both enjoyed the book. -T

10 Mar 2009, 18:56
Albert Oliver (2 posts)


First of all saying that I like the book, is really nice for an introduction and it’s illustrative.

But I also got difficulties the first time I read about rebase, specially in page 125:

bq. With merge tracking, such as Git provides, the effort required to keep everything in sync is greatly reduced, but there is another way

I though “If merging works, why should I bother to learn another way?”. I didn’t understand it, but I kept on reading the section. At the end of it my feelings were like “OK I see the utility of rebase, but I don’t think I’ll never use it”

Of course, with practice, I’ve used it. There’s one scenario when I use it quite often.

When I’m working on more than one feature (with one branch with one feature) and I finish one, I merge that branch into master. Then if I suspect that some of the features I’m still working on can be affected by some change done in master (because of the new merge), I rebase that branch at top of the master, so I have all changes from master in that branch. This scenario can happen when working with several people.

I hope my experience with rebase will be useful to you.

And thanks for the book Travis!

You must be logged in to comment