7

My current pattern is to merge topic branches into my main development branch once they're finished. The log has been getting kind of crazy to look at lately, and I was considering switching to using rebase instead.

What are the possible disadvantages to using rebase instead of merge for topic/feature branches?

Eric
  • 5,842
  • 7
  • 42
  • 71
  • I've seen 'git rebase' fatal on 'not enough memory'. http://stackoverflow.com/questions/6775242/how-can-i-recover-from-fatal-out-of-memory-mmap-failed-cannot-allocate-memor – GoZoner Apr 03 '12 at 20:55

3 Answers3

9

The main disadvantage with using rebase is that you should (read must) only use rebase locally. That is to say, once something has been pushed DON'T rebase it after that. Rewriting history is fine and dandy, but the instant you start screwing around with the history on a remote, things get really messy.

EDIT

Another disadvantage is the fact that the true history is in fact lost. This means, among other things, that it's impossible to go back to the topic branch (easily) since it would have the appearance of being a part of the main branch. It also makes reverting changes much more painful, because you have to cherry-pick one commit at a time, trying your best to remember which ones came from the original topic branch. If you use an interactive rebase, or worse -- squashed your commits down -- then this could be an enormous headache.

Chris Eberle
  • 47,994
  • 12
  • 82
  • 119
  • Would another disadvantage be that it becomes difficult to revert a topic out of the main branch? If so, would you mind adding that to your answer? – Eric Apr 03 '12 at 20:35
  • @Eric yes, that would be one potential disadvantage. I'll update my answer. – Chris Eberle Apr 03 '12 at 20:55
3

Disadvantages include revisions not matching their actual state during development, losing the ability to hide the commits between merges using flags like --first-parent, and being difficult to share your branch if you ever intend it to be rebased later. If your log is looking crazy, take a look at git help log again. Chances are, there is a combination of flags that will make it look just how you want, without sacrificing flexibility when it's desired.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
2

Some reasons:

  • worst problem: you must coordinate your team so everybody uses rebase and understand why they are using it. In my experience you must have git understanding above the average developer so you won't get in trouble with rebase. You must configure your repo so rebase is the default pull strategy.

  • it is usually more difficult to solve conflicts. If you have multiple commits in a feature branch, you probably changed the same code multiple times. If a conflict happens, you'll have to fix it multiple times. With a merge you'd it just once.

  • If you always commit working and tested code, your commit history won't necessarily be something that was working. It is a rare event, but it can mess the use of a git bisect.

BTW, I like to use rebase and recommend it to have a clean history, but you must be aware of the caveats. Also remember that much more important is to have good commit messages and commit granularity.

neves
  • 33,186
  • 27
  • 159
  • 192