为什么这个樱桃采摘会有冲突

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这样的冲突？在这种情况下，樱桃采摘工作的细节是什么

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 pick提交的直接父级(显示它在"b"行之后添加了一行"c"(
• 目标提交(根本不显示行b，它可以在其上应用添加的更改"c"(

因此产生了冲突。

樱桃采摘不像合并(它寻找合并基础(。

Cherry picking需要提交并应用它引入的更改。

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

• 上游(目的地(提交已经"删除了b"(或者一开始就没有，这里就是这样，但Git不知道(
• 源提交具有CCD_ 15，在该CCD_

据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被添加到原始提交中，没有任何冲突(因为您指示了如何使用传递给默认合并策略recursive的选项"-Xtheirs"来解决它(

Answer 2

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

对于冲突的路径，索引文件最多记录三个版本，如gitmerge[1]的"TRUE MERGE"部分所述。工作树文件将包括由通常的冲突标记<lt<lt<lt<以及>>>>>>。

来自git scm文档