Git: Why does rebase result in conflicts while merge does not?

Question

I'm probably not getting something right, but could anyone explain to me why git rebase results in conflicts, while git merge (same branch) does not?

For as far as I know git rebase puts the commits from the other branch before the commits I made on my current branch, while git merge takes those same commits and applies them to my branch as patch, right? Is the diff then not the same, although maybe reversed? Not sure why patching my branch with the other commits is not a problem, while patching the other branch with my commits is.

Answer 1

I see that sometimes my question is still getting an upvote. Let me explain for those that do not understand the currently chosen answer, because I sure didn't when I read it for the first time.

Let's say you have branch master with commits A , B and C .

Then from commit C you create a new branch mybranch . You commit, and you get commits D and E .

In the meantime someone else commits F and G on master.

master then looks like this: ABCFG , while mybranch looks like this: ABCDE .

Now you have two merge strategies:

Merge

While on mybranch , you type git merge master . It takes all the commits from master that you do not have on mybranch - F and G . It first merges F on top of your E (last commit of mybranch ), and then merges G on top of F .

End result: ABCDEFG . Despite these letters being in the same order, the commits were not done (or may not have been done) in chronological order, because actually F and G were (or could have been) done before D and E . You will see a merge commit in this case as well.

Rebase

While on mybranch , you type git rebase master . It takes all the commits from master that you do not have on mybranch - F and G and places those on top of your current branch, brining it in the state that master is currently in (because you branched from master and now get all commits that were done on master since you branched off). It then takes your first commit - D - and merges it on top of G (last commit that was done on master ). Then it takes E and puts it on top of D .

End result: ABCFGDE . It looks as if no branch was ever split off master , and if master is one continuous work, because you kind of said "I want my branch to look as if it was just split off master and then my work was put on top of it". It is the equivalent of checking out master (now ABCFG ), creating a new branch mybranch and then adding your commits ( ABCFGDE ).

Why rebase might result in a conflict while merge does not.

Without going into details, let's just say that it could be that merging master 's F on top of mybranch 's E might not result in a conflict, but merging mybranch 's D on top of master 's F might. It just really depends on which code was changed an if it was a change that is compatible with the previous commit. Merge conflicts may arise in both cases.

Answer 2

During a rebase, you apply all commits of some branch on top of another one. It is possible that one of those commits has a conflict that you solved in a subsequent commit. Hence, the merge operation has no conflict whereas the rebase lead to intermediate conflicts.

See also git rerere which allows you to automatically solve conflicts that you already solved.