Git merge doesn't report merge conflict and picks unexpected end result

问题

I have a nice reproduction script for a scenario in which GIT gives me an unexpected result:

# in an empty directory
git init

echo 4 > a.txt
git add a.txt
git commit -m "initial commit"

git checkout -b test
echo 6 > a.txt
git commit -am "4 => 6"

git checkout -b release master
git merge --no-edit --no-ff test

git checkout master
echo 6 > a.txt
git commit -am "4 => 6"
echo 4 > a.txt
git commit -am "6 => 4"

git checkout release
git merge --no-edit master

Before the last merge a.txt contains 6 and master:a.txt changed it to 4. After merging master, a.txt still contains 6! Why? I expected to see a merge conflict since both branches made changes on the same location.

I know the script may seem concocted and doesn't show use of best of practices. Please focus on why GIT produces the, for me, unexpected result.

Thanks!

回答1:

I have just reproduced your scenario and found the explanation. What happens is that Git looks at only three commits to do the merge, not the intervening history.

Just before the last merge, if you do

MERGE_BASE=`git merge-base master release`
git diff $MERGE_BASE master

you will see no changes reported, since you made a change and undid it on the next commit.

When the three-way merge algorithm compares $MERGE_BASE, master and release, it sees that master did not introduce any changes and therefore accepts the changes in release without conflict.

来源：https://stackoverflow.com/questions/54480730/git-merge-doesnt-report-merge-conflict-and-picks-unexpected-end-result