What is wrong with merge commits?

Question

I see a lot of questions where people are asking how that can avoid "pointless" merge commits.

What exactly is bad about a merge commit? I find them useful, as you can see exactly where two developers started working, and where there work is merged together. It seems like rebasing, as a lot of answers suggest doing, destroys this information and you lose a lot of the project's history.

Is there something I am missing that makes a merge commit undesirable?

Answer 1

There are two different kind of merge commits:

• Explicit merge commits, which result for example from explicitly merging a feature branch into the main branch
• and implicit merge commits, which result for example by doing a git pull before trying to push

The explicit merge commits are usually perfectly fine. You usually even enforce those kind of merge commits by saying git merge --no-ff.

The implicit ones tent to be just noise, as the typical situation is, that one developer changed one file and afterwards another developer works on another file but forgot to pull before doing the changes, and a git pull will implicitly merge both commits by creating a noisy merge commit. The more logical history would be simply one commit from the one author and one commit from the other author. Doing git pull --rebase will exactly do that.

Of course there are exceptions. If both authors actually worked on the same file, it might be better to have a merge commit at this point. - But even in this case maybe a rebase might be better, as it makes the changes against the first commit more explicit and therefore less error-prone.