3

In the past year, most of the rest of my group (of engineers that I work with), has ended up deciding that merge bubbles really aren't that bad.

At the very least, I'm seeing that other developers do not consider rebasing worth the effort needed to avoid merge bubbles when merging (sometimes very badly structured) pull requests.

Why is it actually not that bad to have merge bubbles in your commit history?

To be clear: I am not asking if merge bubbles are bad or not! I am asking why they are not bad.

8

First of all, as you already pointed out, they require less work. In my opinion, the burden is on the process that requires more work—in this case the rebase process—to prove its superior utility.

The biggest argument is that merges preserve an accurate history, as the development actually happened. A linear, consolidated history is useful at a higher level of abstraction, such as the quality and release teams. It's quite the opposite on a development team, where it's extremely useful to know exactly when and how a bug was introduced. Did it happen because of a merge, or was the bug there during development and I just missed it? If the history gets destroyed, you have no way to answer questions like that.

The other reason is it encourages fluid cooperation in other than star topologies. In centralized version control, the only way to share your work is to commit it to the central server. With distributed, you might have two people working together for a day or two, pulling from each other, then they push to the central server once it's ready for the larger group. That's a very efficient and natural way to want to work.

If developers have to worry about if x rebased commit contains the same changes as y commit they pulled from someone else during active development, that creates a cognitive load that discourages that mode of cooperation. Doing merges offloads that tracking effort to the version control software, which is why we have it.

| improve this answer | |
  • 1
    But all pushes are "merges". It seems highly unlikely that a a merge without a conflict would cause any new defects; and if it didn't, it was the commit, not the merge that cause it. If there were no conflicts resolved, why have the unnecessary bubble detail? There's no cognitive load if you just manually merge all pull requests. – Peter Ritchie Oct 7 '14 at 16:02
  • 1
    Merge conflicts only happen when you change the exact same line, or adjacent lines. That's the most likely way for a merge to cause a defect, but not even close to the only way. Developers do much more testing during development than right after a merge. If you can't recreate the last point at which it worked during developer testing and pinpoint the commit that broke it, you're causing a lot of unnecessary grief. For what? So people don't have to use the --first-parent flag to make their log look pretty? – Karl Bielefeldt Oct 7 '14 at 17:03
  • 2
    If you manually merge on every pull requests, you'll only have "unnecessary grief" when there is actually a conflict. And, that's no more "unnecessary" than dealing with a conflict in any other way. But, not manually merging means you've introduced a lot more "unnecessary grief" in all the spurious merge entries in the log--that is, you can't just see that a change was committed. again, every push is a merge if you use the best practice of pushing often you're really getting close to a merge on every commit--this makes the log close to impossible to read, for no good reason. – Peter Ritchie Oct 7 '14 at 17:13
  • @KarlBielefeldt Of all of your arguments, the extra cognitive load was the most compelling: thank you for pointing that out. – Marco Oct 8 '14 at 1:31
2

Whether a satisfactory answer exists to this question is debatable since merge bubbles are desirable for a variety of reasons.

There is less long-term maintenance required when keeping history linear in git, plus it makes it much easier to see what someone was doing rather than attempting to traverse a bushy and complex history. From experience with a large organization and a large number of developers, there is a much higher rate of issues/bugs introduced due to bad merges when compared to rebase.

Honestly, there is not much overhead to keep history linear to avoid merge bubbles. Is it really that hard to add a --rebase option to git pull? Or to set rebase behavior as the default pull behavior in the configuration?

Additionally, the following benenfits are realized when using rebase instead of merge to avoid merge bubbles:

  1. Developers only have to worry about the commits they push when using rebase and not all the complexity and unnecessary commits they added to the history with merges. This greatly simplifies the code review process as well.
  2. Change history analysis is greatly simplified with less time/effort is required.
  3. Reverting changes is a straight-forward process when the history is kept linear through rebase. With merge bubbles in the history, reverting can be more effort than it is worth.

In general, best practices regarding when to use rebase vs merge can be described with the following two use cases:

  1. Rebase should be used for typical development work of individual contributors since it has nearly no additional overhead when compared to a merge.
  2. Merge should only be used by someone in a branch or release management capacity for merging changes between project, organizations, and/or teams.

As a quick disclaimer, with smaller development teams these considerations don't come into play too often, but should still be followed as a best practice. With large organizations though, the benefits of using rebase to keep the history linear greatly outweighs an ill-conceived notion that merge has less overhead than rebase.

| improve this answer | |
  • 2
    This is an excellent answer to the question: "Why are merge bubbles bad" or "Why should merge bubbles be avoided." However, that's not what I'm asking! Please reread the question and either delete or change your answer. – Marco Jan 12 '15 at 8:41
  • 1
    The way the question is phrased then makes it debatable whether an answer exists. I'll update the wording of the question to align with this. – Hazok Jan 12 '15 at 10:19
1

The reason merge bubbles are considered bad in the first place is that they mess up the history log. When it's only one bubble per segment it's not that bad - but when a large team uses merge all the time the history graph starts looking like one of these follow-the-line mazes.

If your team decided that merge bubbles are not so bad, than either:

  1. They are willing to accept the messy history graph
  2. They are willing to use flags like --first-parent to make it look linear
  3. The team is not big enough for this to go out of hand(not likely)
  4. Any other reason that allows you to comply with messy history graphs
| improve this answer | |
  • The link to the image does not work anymore (AccessDenied error message) – Patrick Mevzek Jul 12 '19 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.