为什么这个樱桃挑选会发生冲突？

Question

我知道git cherry-pick 是一个用于应用指定提交更改的命令，但我想我只是不太了解它的工作方式。

假设一个回购行为是这样的：

git init

echo a>a
git add .; git commit -am 'master add line a'

git checkout -b dev
echo b>>a
git commit -am 'dev add line b'
echo c>>a
git commit -am 'dev add line c'

git checkout master

git cherry-pick dev

我认为cherry-pick 命令会运行良好并将文件a 更改为：

a

c

但实际上我收到了以下消息：

error: could not apply 08e8d3e... dev add line c
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

然后我运行：

git diff

输出：

diff --cc a
index 7898192,de98044..0000000
--- a/a
+++ b/a
@@@ -1,1 -1,3 +1,6 @@@
  a
++<<<<<<< HEAD
++=======
+ b
+ c
++>>>>>>> 11fff29... abc

所以我的问题是：为什么会出现 git-diff 显示的冲突？在这种情况下，cherry-pick的工作细节是什么？

Answer 1

在之后再试一次：

git config merge.conflictstyle diff3

您将获得更详细的差异：

<<<<<<< HEAD
||||||| parent of 5b2a14c... dev add line c
b
=======
b
c
>>>>>>> 5b2a14c... dev add line c

这表明，当应用dev的HEAD（b和c）代表的补丁时，Git不知道共同祖先；它遵循：

• cherry-picked 提交的直接父级（表明它在“b”行之后添加了一行“c”）
• 目标提交（它根本没有显示任何行 b 可以应用添加的更改 'c'）

因此发生冲突。

Cherry-picking 不像 merge（它会查找 merge-base）。

Cherry-picking 接受提交并应用它引入的更改。

这里引入的变化是：在b之上添加c。
并且目标提交根本没有b，所以对于Git：

• 上游（目标）提交已“删除 b”（或者一开始就没有，这里就是这种情况，但 Git 不知道），
• 源提交有一个b，在其顶部添加了c。

据 Git 在尝试应用该补丁时所知道的（这就是 git cherry-pick 所做的全部：应用补丁。它根本不查找精选提交的历史记录），这是一个冲突：并发修改。

如果您确定解决方案应该采用的方式，您可以这样做：

> git cherry-pick -Xtheirs dev
[master 7849e0c] dev add line c
 Date: Wed Aug 17 08:25:48 2016 +0200
 1 file changed, 2 insertions(+)

然后，您会看到 b 和 c 添加到原始提交中，没有任何冲突（因为您指示如何使用传递给 default merge strategy recursive 的选项“-Xtheirs”来解决它）

Answer 2

从技术上讲，由于您在不同分支上编辑同一文件的同一行，Git 将此视为冲突。 Cherrypicking 虽然在技术上不是“合并”操作，但仍会寻找相同类型的冲突并要求您解决它们。

对于冲突的路径，索引文件最多记录三个版本，如 git-merge[1] 的“TRUE MERGE”部分所述。工作树文件将包含由通常的冲突标记 >>>>> 括起来的冲突描述。

来自git-scm documentation