Why does git rebase often have less merge conflicts than merge?

I often heard him say that using git rebase reduces the number of merge conflicts, not git merge, but I never found an explanation why this is so.

Just replaying one set of changes on top of another set of changes doesn’t magically dissipate the inherent conflict when two people change the same line of code, so what improves the backup?

Can someone provide a simple example where the merge will have conflicts, but the permutation will not?

UPDATE: after 3 additional years of git experience, I came to the conclusion that my original premise was false: conflicts are equally likely in rebase vs merge. However, Rebase makes the story easier to understand and cherry or rewind if necessary.

+6
source share
1 answer

You resolve conflicts in the commit where they would be introduced, so in reality you don't have them.

If I edit a line in my property branch that has since been changed in the main branch and does a direct merge, it will conflict.

If I reinstall, it will stop at the commit where I made this change, and at that moment I ran into a conflict.

0
source

All Articles