Why do so many projects prefer "git rebase" over "git merge"?

Question

One of the advantages of using a DVCS is the edit-commit-merge workflow (over edit-merge-commit often enforced by a CVCS). Allowing each unique change to be recorded in the repository independent of merges ensures the DAG accurately reflects the true pedigree of the project.

Why do so many websites talk about wanting to "avoid merge commits"? Doesn't merging pre-commit or rebasing post-merge make it more difficult to isolate regressions, revert past changes, etc.?

Point of clarification: The default behavior for a DVCS is to create merge commits. Why do so many places talk about a desire to see a linear development history that hides these merge commits?

Answer 1

People want to avoid merge commits because it makes the log prettier. Seriously. It looks like the centralized logs they grew up with, and locally they can do all their development in a single branch. There are no benefits aside from those aesthetics, and several drawbacks in addition to those you mentioned, like making it conflict-prone to pull directly from a colleague without going through the "central" server.

Answer 2

In two words: git bisect

A linear history allows you to pinpoint the actual source of a bug.

---

An example. This is our initial code:

def bar(arg=None):
    pass

def foo():
    bar()

Branch 1 does some refactoring such that arg is no longer valid:

def bar():
    pass

def foo():
    bar()

Branch 2 has a new feature that needs to use arg:

def bar(arg=None):
    pass

def foo():
    bar(arg=1)

There will be no merge conflicts, however a bug has been introduced. Luckily, this particular one will get caught on the compilation step, but we're not always so lucky. If the bug manifests as unexpected behaviour, rather than a compile error, we may not find it for a week or two. At that point, git bisect to the rescue!

Oh crap. This is what it sees:

(master: green)
|             \_________________________
|                \                      \
(master: green)  (branch 1: green)     (branch 2: green)
|                 |                     |
|                 |                     |
(master/merge commit: green)            |
|                         ______________/
|                        /
(master/merge commit: red)
|
...days pass...
|
(master: red)

So when we send off git bisect to find the commit that broke the build, it's going to pinpoint a merge commit. Well, that helps a little, but it's essentially pointing at a package of commits, not a single one. All ancestors are green. On the other hand, with rebasing, you get a linear history:

(master: green)
|
(master: green)
|
(all branch 1 commits: green)
|
(some branch 2 commits: green)
|
(branch 2 commit: red)
|
(remaining branch 2 commits: red)
|
...days pass...
|
(master: still red)

Now, git bisect is going to point at the exact feature commit that broke the build. Ideally, the commit message will explain what was intended well enough to do another refactor and fix the bug right away.

The effect is only compounded in large projects when the maintainers didn't write all the code, so they don't necessarily remember why any given commit was done/what each branch was for. So pinpointing the exact commit (and then being able to examine the commits around it) is a great help.

---

That said, I (currently) still prefer merging. Rebasing onto a release branch will give you your linear history for use with git bisect, while retaining the true history for day-to-day work.

Answer 3

In short, because merging is often another place for something to go wrong, and it only needs to go wrong once to make people very afraid of dealing with it again (once bitten twice shy, if you will).

So, let's say we're working on an new Account Management Screen, and it turns out there is a bug discovered in the New Account workflow. OK, we take two separate paths - you finish the Account Management, and I fix the bug with New Accounts. Since we are both dealing with accounts, we've been working with very similar code - perhaps we even had to adjust the same pieces of code.

Now, at this moment we have two different but fully working versions of software. We've both run a commit on our changes, we've both dutifully tested our code, and independently we are very confident we've done an awesome job. Now what?

Well, it's time to merge, but...crap, what happens now? We could very well go from two working sets of software to one, unified, horribly broken piece of newly buggy software where your Account Management doesn't work and New Accounts are broken and I don't even know if the old bug is still there.

Maybe the software was smart and it said there was a conflict and insisted we give it guidance. Well, crap - I sit down to do it and see you've added some complex code I don't immediately understand. I think it conflicts with the changes I've made...I ask you, and when you get a minute you check and you see my code that you don't understand. One or both of us have to take the time to sit down, hash out a proper merge, and possibly retest the whole dang thing to make sure we didn't break it.

Meanwhile 8 other guys are all committing code like the sadists they are, I made a few small bug fixes and submitted them before I knew we had a merge conflict, and man it sure seems like a good time to take a break, and maybe you are off for the afternoon or stuck in a meeting or whatever. Maybe I should just take a vacation. Or change careers.

And so, to escape this nightmare, some people have become very afraid of commitment (what else is new, amiright?). We're naturally risk averse in scenarios like this - unless we think we suck and are going to screw it up anyway, in which case people start acting with reckless abandon. sigh

So there you go. Yes, modern systems are designed to ease this pain, and it's supposed to be able to easily back out and rebase and debase and freebase and hanglide and all that.

But it's all more work, and we just want to push the button on the microwave and have a 4-course meal done before we have time to find a fork, and it all feels so very unfulfilling - code is work, it's productive, its meaningful, but gracefully handling a merge just doesn't count.

Programmers, as a rule, have to develop a great working memory, and then have a tendency to immediately forget all that junk and variable names and scoping as soon as they've finished the problem, and handling a merge conflict (or worse, a wrongly handled merge) is an invitation to be reminded of your mortality.

Answer 4

Rebasing provides a moving branch point which simplifies the process of pushing changes back to the baseline. This allows you to treat an long running branch as if it were a local change. Without rebasing, branches accumulate changes from the baseline which will be included in the changes being merged back to baseline.

Merging leaves your baseline at the original branch point. If you merge a few weeks worth of changes from the line you branched off of, you now have a lot of changes from your branch point, many of which will be in your baseline. This makes makes it difficult to identify your changes in your branch. Pushing changes back to the baseline may generate conflicts unrelated to your changes. In the case of conflicts, it is possible to push inconsistent changes. Ongoing merges take effort to manage, and it is relatively easy to loose changes.

Rebase moves your branch point to the latest revision on your baseline. Any conflicts you encounter will be for your change(s) alone. Pushing changes is much simpler. Conflicts are dealt with in the local branch by doing an additional rebase. In the case of conflicting pushes, the last one to push their change will need to resolve the issue with their change.

Answer 5

The automated tools are getting better at making sure that the merging code will compile and run, thus avoiding syntactic conflicts, but they cannot guarantee the absence of logical conflicts that may be introduced by merges. So a 'successful' merge gives you a sense of false confidence, when in reality it guarantees nothing, and you have to redo all of your testing.

The real problem with branching and merging, as I see it, is that it kicks the proverbial can down the road. It lets you say "I'll just work in my own little world" for a week, and deal whatever problems come up later. But fixing bugs is always faster/cheaper when they are fresh. By the time all of the code branches start getting merged you may already forget some of the nuances of the things that were done.

Take the two aforementioned problems together, and you might find yourself in a situation where it's simpler and easier to have everyone work out of the same trunk and continuously resolve conflicts as they come up, even if they make active development a little slower.

Answer 6

Three things haven't been said in any of the answers:

• Diffing inside a branch:

  • Diffing between an arbitrary pair of commits in a branch becomes extremely difficult when there are merge commits.

• Merging one item at a time:

  • When you're resolving the difference between two branches, a merge typically happens all at once, and any merge conflicts you're left to do without context of which specific commit was responsible for the conflict. If you rebase, the rebase will stop at the point the conflict occurred and allow you to resolve it in that context.

• Cleanup before push:

  • If you made a mistake commit that you later need to fix, if you've not pushed interactive rebase will allow you to combine/split/change/move commits. While you can still do that if you've merged, it becomes very difficult if you want to combine/split/change/move across a merge boundary.

Answer 7

An additional relevant point is this: With rebasing I can easily cherry pick or revert a feature in my release branch.

Answer 8

At my company we use probably 90% merge and 10% rebase, depending on what we're trying to do. We can actually see which branches need to be rebased based on our branching strategy by using a tool like git extensions or git kraken. Most of the time, we create a release branch from master and then pull in all the code that passed QA, with a standard merge. It makes like a mini van picture:

Code that doesn't make cutoff needs to be rebased. Once a new version of master is in production, you rebase the branches that carried over from last sprint. This helps azure devops not get confused and put out the multiple merge base warning. Rebasing shifts the branch to a new starting point, so that all your branches have a single base.