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

Question

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

Answer 1

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

基础

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

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

另一方面，

Git通过将所有文件的快照存储在当前工作目录中来记录修订。

最好用an image书中使用的Pro Git来说明：

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

在Git中，它看起来更像是{from the Pro Git book）：

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

  

为了提高效率，如果文件没有更改，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所做的所有修改的结果，并且已经通过了先前的修订。