Does git rebase create more conflicts than git merge?

Question

Is it true that git rebase is more prone to conflicts than git merge? I have heard that before and it is referenced in this post

I am speculating based on anecdata here, but I suspect the general anxiety around rebasing stems from two primary places:

1. Due to the mechanics of git rebase, merge conflicts are more frequent and seemingly harder to deal with

The author doesn't go into detail to justify that claim, but it is not the first time I hear it.

I have heard and understand the point that because rebase replays commit by commit you will end up with the same conflict several times, but I have never encountered that. Maybe the rerere behaviour is now default in git rebase?

I am trying to propose a rebase policy in my team but I want to address this issue if it is accurate.

Honestly, I would expect to have the same number of conflicts since a change in both branches will end up with a conflict, regardless of rebase or merge. In other words, the conflict is not caused by the convergence of the branches at the end, it is cause by parallel changes to the same line

Answer 1

You'll end up with more conflicts with a rebase if you have multiple commits. This is because when you rebase you'll have to solve conflicts for each commit. That means if you're trying to rebase a branch that is 5 commits ahead of your master and you introduced a merge conflict in the first of those 5 commits you'll have to resolve that conflict in each of the following commits.

Rebasing often should fix the issue above. Also it's worth mentioning that if you want to squash down to a single commit there is a simpler strategy than rebase.

Let's say you have 5 commits you want to merge in master, but it's only one feature that can easily be described in one commit with a descriptive message.

git fetch
git merge origin/master
git reset --soft origin/master
git commit

If you just want a single commit this is way easier and accomplishes the same thing as rebasing.