为什么git cherry-pick冲突包括上一次提交的更改

Question

我有一个暂存分支，在其中我对某个功能进行了一些提交，而我需要从master分支进行这些提交。我尝试使用来从master分支中签出一个分支git checkout -b branch_name，然后使用 进行了我想要从登台分支中挑选的第一笔提交 git cherry-pick hash。出于某种原因，与樱桃采摘有冲突，但是该冲突包括从先前提交到樱桃采摘的更改，为什么呢？

Answer 1

TL; DR与其他VCS相比，您所看到的与Git如何记录和存储文件历史直接相关。

基础

掌握它的最简单方法是考虑修订（或版本）的概念。

传统上，版本控制系统通过存储文件的当前状态与先前版本中的文件之间的差异（也称为增量或？）来在您的工作目录中记录文件的修订。

另一方面，Git通过将所有文件的快照存储在当前目录中来记录修订。

最好用Pro Git书中使用的图像来说明：

在这里，您将看到传统的VCS如何仅在修订之间的每个文件中存储差异。

在Git中，它看起来更像这样（同样来自Pro Git书）：

您会看到每个修订都与工作目录中所有文件的快照相关联。但是，文档指出：

为了提高效率，如果文件没有更改，Git不会再次存储该文件-只是指向它已经存储的先前相同文件的链接。

但是，从概念上讲，您仍然可以想到每次提交都指向整个工作目录的快照。

采摘樱桃

现在，考虑一下当您选择一个提交时会发生什么。假设我们要挑选与对应的提交Version 5：

git cherry-pick <version-5>

Git将转到merge与所引用的提交关联的快照HEAD（即，您的工作目录中的文件）以及与关联的快照version-5。

现在，如果version-4以与工作目录中的显示方式相冲突的方式修改file B（导致file B1）中的一行file B，则会产生冲突。这是重要的部分：

即使version-5（您正在挑选的file B那个）以不与任何内容冲突的方式进行了相同的修改，也会发生冲突。

这是因为与version-5包含的快照有关file B2，这是所有修改的结果，file B已经通过了先前的修订。