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.
2 Answers
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: A B C F G, while mybranch looks like this: A B C D E.
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: A B C D E F G. 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.
