Git合并不会报告合并冲突，并且会选择意外的最终结果 [英] Git merge doesn't report merge conflict and picks unexpected end result

问题描述

对于GIT给我带来意外结果的场景，我有一个不错的再现脚本:

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

在最后一次合并之前，a.txt包含6，而master:a.txt将其更改为4.合并master之后，a.txt仍然包含6！为什么?我希望看到合并冲突，因为两个分支都在同一位置进行了更改.

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.

我知道该脚本似乎是经过精心编写的，并未显示出最佳实践的使用.请重点介绍GIT为什么会为我产生意想不到的结果.

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.

谢谢！

推荐答案

我刚刚复制了您的方案并找到了解释.发生的事情是，Git仅查看三个提交来进行合并，而不是中间的历史记录.

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.

当三元合并算法比较$MERGE_BASE，master和release时，它会发现master没有引入任何更改，因此接受了release中的更改而没有冲突.

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.

这篇关于Git合并不会报告合并冲突，并且会选择意外的最终结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！