出于某种原因，当苍蝇出现合并冲突时，看起来git cherry-pick会在其他提交中拉动。当我们使用git mergetool时，这些会消失，但会阻止我们手动编辑合并冲突的文件。
有谁知道为什么会这样？
为了说明我的意思，让我们用一个新的git 1.7.4存储库和一个文件foo：
header
footer
让我们在此处创建一个名为bar的新分支。回到master中，让我们在单独的提交中为这个文件添加三个更改。
提交1：
header
+add something
+
footer
提交2：
header
add something
+add something else
+
footer
承诺3：
header
add something
add something else
+important change!
+
footer
由于最后一次提交很重要，因此我们决定将其拉回到该分支上的分支bar和git cherry-pick <commit>。
不幸的是，这会在文件foo中产生一个有趣的合并冲突：
header
<<<<<<< HEAD
=======
add something here
add something else here
important change!
>>>>>>> 356ca3c... important change
footer
请注意，git mergetool似乎做了正确的事并产生了这个：
header
+important change!
+
footer
为什么合并冲突的文件包含我们试图挑选之前的提交？
答案 0 :(得分：0)
Git持怀疑态度，如果没有找到补丁所适用的边缘，则不会进行合并。该补丁将应用于不存在的行号。检查该提交的补丁，看看它是否应用于没有意义的行号。因为它是一个挑选，它没有考虑文件是如何成为那样的，并且可以添加该条目。希望这是有道理的。