I think the most likely reason would be that a commit has been cherry-picked from one branch involved in the merge to the other. If rebase detects that a commit it's about to rewrite applies the same textual changes as a commit already included in the new base, then it skips that commit. (There's probably something inexact about that explanation, but it's roughly right...)
So if you have
x -- A -- B -- C <--(master)
\
D -- A' -- E <--(branch)
where A'
makes the same changes to D
that A
made to x
(perhaps it was cherry-picked, or rebased, or squash merged...), then
git rebase branch master
would rewrite D
and E
, skipping A'
. But
git checkout master
git merge branch
would not look at the individual commits, so you could get conflicts due to the changes in A'
.