Yesterday I started into the topic of git rebase vs merge. Some swear merging is better, others rebasing.

Today I’ll talk about why merging is better. If you’re in the rebase camp, hold your fire until tomorrow, please 😉

So without further ado, here are the times when I believe merging is better than rebasing:

• You’re mering a feature branch into your main branch. (Rebasing main onto a feature branch doesn’t really make sense, does it?) Of course, you don’t need to branch at all. You could be doing trunk-based development, and commit directly to main. But if you’re doing that, you’re probably not reading this.

• You want to hit the “Update Branch” button in GitHub (or equivalent in your VCS) to allow your branch to merge, when “require up to date branches” is enabled.

• You don’t know what rebasing is.

• You have a really big feature branch, which now has conflicts with the main branch, and you want to resolve them all in one fell swoop, so you merge main back into your feature branch.

• You like the way git history looks with Merge branch 'main' into ... messages scattered about, and the “diamond-shaped” merge graph it produces.

  

• You like making git bisect harder to use.

Okay, so most of these aren’t serious reasons, as you can tell.

The truth is that the third and fourth reasons above are the most common ones I hear (although not necissarily in as many words) for using merging: The person is unfamiliar with using rebase as an alternative, or they are familiar, and they find that rebase is more work.

Rebase often is more work. But as I’ll discuss tomorrow, I think it’s usually worth it.

Of course, better than doing more work is not using large feature branches at all, as I discussed yesterday. Then this question doesn’t matter at all.