樱桃选择是应用更改还是尝试合并整个文件的内容？

Question

我正在阅读这篇文章关于樱桃采摘的文章，下面是一张图片：

​

​

然而，这幅画对我来说似乎是误导人的。从我的简单测试来看，似乎不仅仅是差异，而是整个文件内容被合并了。下面是一个实验:我有一个提交图：

A--B
 \
  C

提交A在file.txt中包含了此内容

l1
l2
l3

Commit B有一些小的更改：

l1
l2-new
l3

Commit C有一些小的更改：

l1
l2
l3-new

所以现在我试着用樱桃选择在提交B上重放提交C，

git cherry-pick B

我遇到了冲突，

<<<<<<< HEAD
l2
l3-new
=======
l2-3
l3
>>>>>>> C

如果只应用了更改，就不应该出现这种情况。因为我在我的l2提交中没有接触到C行，所以它应该应用得很顺利。我说的对吗？

Answer 1

Git存储文件，但它在许多地方生成和使用差异。

diff记录提交前后受影响行的状态；它还存储修改区域之前和之后的一行文本。Git使用这些信息来避免数据丢失和不一致。

假设我们在提交时创建了名为A、B和C的分支，这些名称包含在您的描述中。

$ git diff A B -- file.txt
diff --git a/file.txt b/file.txt
index f0f2307..0acba21 100644
--- a/file.txt
+++ b/file.txt
@@ -1,3 +1,3 @@
 l1
-l2
+l2-new
 l3

我要求Git在提交A和B之间显示文件file.txt上的更改。

这种格式是uniffied格式的一个变体，它在维基百科页面上对diff utility进行了解释。

简单地说，这个diff是:将文件的第2行从l2改为l2-new，但前提是第1行是l1，第3行是l3。即使只更改了文件的第2行，Git也包括diff中文件的第1行和第3行。它们是第2行发生的更改的上下文。

注释:在本例中，文件很小，第1-3行表示整个文件。Git不使用整个文件，它只保护更改前1行和更改后1行更改的任何行块。例如，如果文件有20行，而我们更改了第12和第13行，则diff包含第11-14行。

回到我们的diff，在提交C时，文件如下所示：

l1
l2
l3-new

但是为了应用diff，Git希望它看起来像：

l1
l2
l3

由于它的期望没有得到满足，Git无法安全地应用diff，并决定这是一个冲突。

为什么Git需要上下文行？

假设在提交C时，我们删除了第二行。该文件如下所示：

l1
l3

然后我们选择提交B，并在不验证上下文的情况下应用它引入的更改(将第2行从l2更改为l2-new)。该文件现在看起来如下：

l1
l2-new

等一下！在哪里？

我没有删除提交C上的行C，也没有在提交B上碰它。在不检查上下文的情况下应用diff，可能会导致数据丢失。 Git在应用diff时总是检查上下文，我认为所有使用diffs的程序都会这样做。

Answer 2

由于更改太近(行号的术语)，所以最终会出现冲突。上下文(通常是围绕实际差异块的3行)需要匹配，否则Git (和其他版本控制系统)将将更改标记为冲突。由于部分上下文在您的示例中发生了更改，因此它被标记为冲突。

Answer 3

Git存储的是文件，而不是差异，因此mb由于行接近，所以git无法正确地解析它。