git - git merge 冲突究竟何时发生

Question

我正在使用 git 来跟踪对 LaTeX 文档的更改。我倾向于将共同作者的反馈保留在一个单独的分支中，然后再 merge 。到目前为止，事情似乎神奇地正确 merge ，但我想知道 merge 冲突究竟何时发生，以便我可以在 merge 过程中获得一些真正的信任(我当然不希望文本变得时髦)。

StackOverflow 上有很多问题似乎都在问同样的问题，但没有一个答案非常具体。例如 this answer指定如果对同一区域进行更改，则会发生冲突，但这让我想知道这些区域到底是什么。它只是对同一行所做的更改，还是考虑了某些上下文？

Answer 1

它是一行一行的，答案是“否”和"is":上下文确实很重要，但重要的数量是棘手的。它比您最初想象的要多或少。

您可能想浏览一下 this answer首先是一个相关的问题，作为背景。我现在假设我们有 base作为(单个) merge 基础(也许我们通过标记特定提交来设置名称 base，例如， git tag base $(git merge-base HEAD other) )和 HEAD作为我们在分支 b1 上的提交，还有其他一些分支名称 b2命名另一个提交。

接下来，我们看看两个差异:

git diff base HEAD
git diff base b2

如果我们看到文件 F 的所有三个版本都不同(因此 F 出现在两个输出中，并且更改不同)，那么我们必须在本质上使用 diff-hunk-by-diff-hunk。在差异块重叠但进行不同更改的地方，Git 声明冲突。但是——这似乎是你的问题——“做出不同的改变”究竟是什么意思？

我认为这是最好的例子。例如:

$ git checkout b1
[checkout messages here - but I was already on b1]
$ git diff base HEAD
diff --git a/basefile b/basefile
index df781c1..e4f9e4b 100644
--- a/basefile
+++ b/basefile
@@ -4,6 +4,7 @@
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions
 # are met:
+# added line in b1
 # 1. Redistributions of source code must retain the above copyright
 #    notice, this list of conditions and the following disclaimer.
 # 2. Redistributions in binary form must reproduce the above copyright

和:

$ git diff base b2
diff --git a/basefile b/basefile
index df781c1..c96620e 100644
--- a/basefile
+++ b/basefile
@@ -4,7 +4,6 @@
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions
 # are met:
-# 1. Redistributions of source code must retain the above copyright
 #    notice, this list of conditions and the following disclaimer.
 # 2. Redistributions in binary form must reproduce the above copyright
 #    notice, this list of conditions and the following disclaimer in the

请注意，虽然这些更改不涉及同一条线，但在某种意义上，它们也确实涉及同一条线。我添加了第 7 行(将旧的第 7 行推到第 8 行)，并删除了旧的第 7 行。显然，这些是“相同”的行。所以:

$ git merge b2
Auto-merging basefile
CONFLICT (content): Merge conflict in basefile
Automatic merge failed; fix conflicts and then commit the result.

让我们中止这次 merge 并考虑分支 b3 的尖端相反(在我的设置中， b1 和 b3 的 merge 基数与 b1 和 b2 的 merge 基数相同)。

$ git merge --abort
$ git diff base b3
diff --git a/basefile b/basefile
index df781c1..e2b8567 100644
--- a/basefile
+++ b/basefile
@@ -5,7 +5,6 @@
 # modification, are permitted provided that the following conditions
 # are met:
 # 1. Redistributions of source code must retain the above copyright
-#    notice, this list of conditions and the following disclaimer.
 # 2. Redistributions in binary form must reproduce the above copyright
 #    notice, this list of conditions and the following disclaimer in the
 #    documentation and/or other materials provided with the distribution.
 $ git merge --no-edit b3
Auto-merging basefile
Merge made by the 'recursive' strategy.
 basefile | 1 -
 1 file changed, 1 deletion(-)

这一次没有冲突，即使两个 diff 大块头都触及了相同的一般区域。第二个 diff 删除了没有“接触”添加行的行，因此 Git 认为这是安全的。

如果您以同样的方式进行更多实验，您将准确地发现哪些看似重叠的更改成功组合，哪些会导致冲突。显然，直接重叠的更改，例如，删除原始行 42 并插入不同的新行 42，将发生冲突。但是所有更改始终表示为“删除一些现有行，尽管可能为零”，然后是“添加一些新行，但可能为零”。更改(即使只是更改、添加或删除一行中的一个单词)会删除非零数量的现有行并添加非零数量的新行。纯删除(一个或多个完整行)添加零行，纯插入删除零行。最后，它归结为:“我们和他们的更改是否涉及相同的行号？”上下文变得几乎无关紧要，除了在删除零行或插入零行时，上下文本身在某种意义上“就是”行。 (我不确定这个说法有多大意义，所以如果它难以理解，那是我的错。;-))

(还请记住，如果您在工作时修改“到目前为止已 merge ”的文件，则在查看更改是否触及“相同”行时，您必须使用原始基本文件的行号。由于“我们的”和“他们的” "具有相同的基本版本，这是我们可以在此处使用的简单快捷方式。)

三路 merge 不是补丁

请注意，这与应用补丁不同，后者无需通用基础版本即可启动。在补丁的情况下，上下文使用得更多:差异块头提供了搜索上下文的位置，但由于它可能应用于文件的不同版本，上下文允许我们(和 Git)只要上下文仍然匹配，就可以在不同的行进行相同的更改。
patch实用程序在这里使用不同的算法(“最大模糊”因子，看起来 +/- 那么多行)。 Git 不做模糊因素；如果必须，它将一直搜索到文件的开头或结尾。但是，在确定上下文无法匹配之前，它确实具有调整空白的常用选项。

(当使用 git apply 应用补丁时，您可以添加 -3 或 --3way 以允许 Git 读取 index 行，这些行提供文件 blob 的部分或完整哈希 ID。左侧的哈希 ID 是文件先前版本的哈希值:请注意，在上述所有差异中， basefile 的“基本”版本具有 ID df781c1 。如果 Git 可以从该 ID 中找到唯一的 blob，它可以假装这是 merge 基，并且仅针对 HEAD 比较一个 merge 基，将补丁本身视为另一个差异，并以这种方式进行三向 merge 。这有时允许 git apply 成功，而 patch 会失败.)