What are the downsides to rebasing topic branches instead of merging?

Question

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?

Courbevoie

I've seen 'git rebase' fatal on 'not enough memory'. #6775742 – Xuanxunit

Answer 1

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.

Bickering

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? – Courbevoie

@Courbevoie yes, that would be one potential disadvantage. I'll update my answer. – Bickering

Answer 2

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.

Helfand

Answer 3

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. If some uses merge, you history will be messed. You should 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 to understand your history is to have good commit messages and commit granularity. It is easier to teach this to your developers than rebase.

Remember that we are paid to deliver features and working code, not to play with our version control system :-)

Prebendary