问题
I've often heard it said that using git rebase reduces the number of merge conflicts as opposed to git merge, but I've never found an explanation of why this is the case.
Simply replaying one set of changes on top of another set of changes doesn't magically dispel the inherent conflict when two people both modify the same line of code, so what makes rebase better?
Can anyone provide a simple example where a merge would have conflicts but a rebase doesn't?
UPDATE: After 3 additional years of git experience, I've come to believe that my original premise was false: conflicts are equally likely in rebase vs merge. Rebase does however make history easier to comprehend and cherry-pick or rewind when needed.
回答1:
You resolve the conflicts in the commit where they would have been introduced, so in effect, you don't have any.
If I edit a line in my feature branch which has since changed in the master branch, and do a straightforward merge, it will conflict.
If I rebase, it will stop at the commit where I made this change and at that point I deal with the conflict.
来源：https://stackoverflow.com/questions/13181212/why-does-git-rebase-often-have-fewer-merge-conflicts-than-a-merge