git - Git:关于 merge 算法，冲突格式以及与mergetools相互作用的困惑

Question

我不知道细节，但是据我所知，合并和冲突解决过程如下（假设存储库中只有一个文件，在两个分支中有修改）：


用户发出git merge命令。
Git应用了一些特定于git的算法来自动合并两个修改过的文件。为此，它将创建该文件的BASE，LOCAL，OTHER和BACKUP版本。
然后将合并结果写入原始跟踪文件（称为MERGED）。
假设有冲突。 Git使用某种格式来表示冲突（<<<<<<<，|||||||，=======，>>>>>>>标记）。然后，将其状态设置为“合并”或类似状态。
如果用户随后发出git mergetool ...，则将打开配置的外部合并工具，其参数指向BASE，LOCAL，OTHER，当然也指向MERGED。


我有些困惑：


该工具会始终了解Git的冲突格式吗？它是标准化的吗？ diff3选项呢？外部工具也通常理解它吗？
该工具是否会应用自己的（也许是不同的）合并算法，并完全丢弃Git的输出？
当Git需要执行递归合并（由于多个合并基数）并且中间合并会产生冲突时，是否会将内部冲突标记与其他任何非冲突文本一样视为纯文本？还是冲突格式本身是递归的？


我找不到任何能真正说明整个故事的解释。

Answer 1

完整的答案很复杂。爱德华·汤姆森的大部分内容。这里要详细得多。

不过，让我们从这里开始：git mergetool运行-我应该说，您运行它-在完成所有git merge的操作之后。您的合并工具甚至在git merge完成之前（由于冲突而失败）才输入图片。这改变了您思考这些问题的方式。

（递归和解决）合并的工作方式


用户发出git merge命令。


到目前为止，一切都很好。


Git应用了一些特定于git的算法来自动合并两个修改过的文件。


哎呀，不，我们已经出轨了，火车可能正驶离悬崖。 :-)

此时的第一步是选择合并策略。让我们选择默认（-s recursive）策略。如果我们选择其他策略，则下一步可能会有所不同（-s ours完全不同，而-s octopus则有所不同，但是现在这些都不是很有趣的事情）。

下一步是找到所有合并基础。运气好的话只有一个。稍后我们将讨论递归问题。但是，可能没有合并基础。较旧的Git版本使用一棵空树作为假合并基础。较新的版本（2.9或更高版本）要求您在此处添加--allow-unrelated-histories（然后以相同的方式进行）。对于空的树，将在两个非基本提交中添加每个文件。

如果存在一个合并基础，则它可能与任一分支提示相同。如果是这样，则没有要执行的合并。不过，这里也有两个子情况。可能没有要合并的内容，因为合并的基础是另一个提交，而另一个提交位于当前提交的“后面”（是该提交的祖先）。在这种情况下，Git始终不执行任何操作。或者，另一个提交可能在当前提交之前（其后代）。在这种情况下，除非您指定--no-ff，否则Git通常会执行快进操作。在两种情况下（快进或--no-ff），都不会发生实际的合并。相反，将提取进一步提交。它要么成为当前提交（快速合并：无论您在哪个分支上，现在都指向更进一步的提交），要么Git使用该提交的树进行新提交，并且新提交成为当前提交。

真正的合并：将一个合并库与两个提交合并

现在，我们处于一个合并基本提交B，两个提交L（本地或左侧，--ours）和R（远程或右侧，--theirs）的阶段。现在，两个常规策略（-s recursive和-s resolve）在启用重命名检测的情况下执行了一对git diff --name-status操作，以查看B-to-L更改中是否存在更改其名称的文件，以及是否存在B对R更改中的文件会更改其名称。这还将找出L或R中是否有新添加的文件，以及L或R中是否有文件被删除。所有这些信息被组合以产生文件标识，以便Git知道要组合的更改集。这里可能存在冲突：例如，一个文件的路径是基础中的PB，但现在同时是PL和PR，存在重命名/重命名冲突。

此时的任何冲突（我称它们为高级冲突）都不在文件级合并的范围内：它们会使Git结束此合并过程而发生冲突，无论发生什么其他情况。但是，与此同时，正如我上面所说，我们最终得到的是“已识别文件”，但并没有对其进行完全定义。松散地，这意味着仅仅因为某些路径P被更改，并不意味着它是一个新文件。如果基本提交B中有一个文件base，并且现在在L中将其称为renamed，但在R中仍将其称为base，则Git将使用新名称，但将B：base与L：renamed和B进行比较。当Git在文件级别组合更改时，使用：base和R：base。

换句话说，我们在此阶段计算的文件身份告诉我们（和Git）B中的哪些文件与L和/或R中的哪些文件匹配。此身份不一定是路径名。通常，所有三个路径都匹配。

您可以在第一个diff阶段插入一些小调整：


重新规范化（merge.renormalize）：您可以使Git从.gitattributes和/或core.eol设置应用文本转换。 .gitattributes设置包括ident过滤器以及任何污迹和清洁的过滤器（尽管此处仅污迹方向适用）。

（我以为Git会这样做很早，因为它可能会影响重命名检测。不过，我实际上并未对此进行测试，而且我只是查看了Git源代码，似乎在此阶段未使用它。所以也许merge.renormalize不会即使有污点的过滤器可以从根本上重写文件，也可以在这里应用。例如，考虑使用一对加密和解密的过滤器对，这可能是一个错误，尽管很小，但幸运的是，EOL转换对相似性索引值完全没有影响）
您可以设置Git将何时考虑重命名文件的相似性索引，或者完全禁用重命名检测。这是-X find-renames=n扩展策略选项，以前称为重命名阈值。它与git diff -M或--find-renames选项相同。
Git当前无法设置“中断”阈值la git diff -B。这也会影响文件身份计算，但是如果您不能设置它，那实际上就没有关系。 （您可能应该可以设置它：另一个小buglet。）


合并单个文件

现在我们已经确定了文件并确定了哪些文件与其他文件匹配，我们最终进入文件合并级别。请注意，在这里，如果您使用内置的合并驱动程序，剩下的可设置diff选项将变得很重要。

让我再次引用这一点，因为它是相关的：


Git应用了某种算法来自动合并两个修改过的文件。为此，它将创建该文件的BASE，LOCAL，OTHER和BACKUP版本。


此时涉及三个（不是四个）文件，但是Git不会创建任何文件。它们是来自B，L和R的文件。这三个文件在存储库中作为Blob对象存在。 （如果Git正在对文件进行规范化，那么它确实必须在此时将其创建为blob对象，但随后它们就存在于存储库中，而Git只是假装它们在原始提交中。）

下一步非常关键，这就是索引进入图片的位置。这三个Blob对象的哈希ID为HB，HL和HR。 Git准备将这三个哈希分别放入插槽1、2和3中的索引中，但是现在使用the git read-tree documentation under the 3-Way Merge section中描述的规则：


如果所有三个哈希都相等，则文件已经合并并且什么也没有发生：哈希进入插槽0。即使只有第二个和第三个哈希相等，该文件仍然已经合并：L和R都对B进行了相同的更改。新的哈希值进入插槽0，文件合并完成。
如果HB = HL且HB≠HR，则应为右侧文件（远程/其他/ --theirs）。该哈希值进入插槽0，文件合并完成。
如果HB≠HL且HB = HR，则应为左侧（本地/ --ours）文件。该哈希值进入插槽0，文件合并完成。
这仅保留了所有三个哈希都不同的情况。现在，文件确实确实需要合并。 Git将所有三个哈希放入三个索引槽。


此时有一些特殊情况可以应用，所有这些都与更高级别的冲突有关。对于某些路径名，可能会将一个或两个索引槽留空，因为对索引进行了精心的管理，使索引与工作树保持同步（这样它就可以充当缓存的角色，从而加快Git的工作）。很多）。但是原则上，尤其是当我们关注合并驱动程序时，我们可以将其视为“所有三个插槽”，对于重命名的文件，它们可能只是分布在多个名称上的三个插槽。

调用合并驱动程序（.gitattributes）

至此，我们已经执行了实际的文件级合并。我们有三个输入文件。它们的实际内容作为blob对象存储在资源库中。它们的哈希ID存储在索引的插槽1到3中（通常是单个索引条目，但是在重命名的情况下，可能使用多个索引条目）。我们现在可以：


使用git的内置文件合并（也可以作为外部命令git merge-file使用）。

内置的文件合并直接从索引开始（尽管如果要通过git merge-file运行它，则必须将blob提取到文件系统中）。它提取文件，执行合并这些文件的任务，并视扩展策略选项-X ours或-X theirs的需要而定，还可以编写冲突标记。它将最终结果放入Git选择作为最终路径名的路径名下的工作树中，并完成操作。
使用合并驱动程序（通过.gitattributes）。合并驱动程序为run with arguments。但是，这些参数是通过让Git将三个Blob对象提取到三个临时文件来构造的。

参数是从我们以%O，%A，%B，%L和%P输入的任何内容扩展的。这些自变量字母与我们一直在使用的不完全匹配：%O是基础文件的名称，%A是左侧/本地/ --ours版本的名称，%B是名称右侧/其他/远程/ --theirs版本的%L是conflict-marker-size设置（默认为7），而%P是Git用来在工作中保存最终结果的路径-树。

请注意，%O，%A和%B都是Git创建（用于保存blob内容）的临时文件的名称。它们都不符合%P。 Git希望合并驱动程序将合并结果留在路径%A中（然后Git会自行将其重命名为%P）。


在所有情况下，此时合并文件都进入工作树。如果合并顺利，则将清除索引中编号较高的插槽：实际上，Git在工作树文件上运行git add，将数据作为blob对象写入存储库，并获取哈希ID进入插槽0。如果合并由于冲突而失败，则编号较高的插槽将保留在原位置；插槽零为空。

所有这些的最终结果是工作树保存了合并的文件（可能带有冲突标记），而索引保存了合并的结果（也许带有应该解决的冲突）。

使用git mergetool

这与合并驱动程序的工作方式几乎相同。但是，除了仅在合并完成后才在索引和工作树中运行其结果之外，主要区别是：


git mergetool将制作文件（.orig文件）的额外副本。
它确切地知道如何运行每个已知的工具，即，传递哪些参数以使该工具发挥作用。例如，没有等效的驱动程序%O占位符。
它可以对某个目录中所有尚未合并的文件运行命令。


实际上，git mergetool是一个很大的shell脚本：它使用git ls-files -u查找未合并的索引条目，并使用git checkout-index从索引中提取每个阶段。对于更高级别的冲突，它甚至具有特殊情况，例如添加/添加或重命名/删除。

每个已知工具还有一个额外的驱动程序shell脚本片段：

$ ls $(git --exec-path)/mergetools

查看所有单独的工具驱动程序。这些标志传递给 $base_present标志，用于处理添加/添加冲突。 （它们是通过 . "$MERGE_TOOLS_DIR/$tool"运行的，以便它们可以覆盖脚本中定义的shell函数。）

对于未知工具，您可以使用外壳程序的变量名称 $BASE， $LOCAL和 $REMOTE来了解脚本将从索引中提取的三个文件放在何处，然后将结果写入 $MERGED（位于事实上文件的工作树名称）。该脚本执行此操作：

setup_user_tool () {
        merge_tool_cmd=$(get_merge_tool_cmd "$tool")
        test -n "$merge_tool_cmd" || return 1

        diff_cmd () {
                ( eval $merge_tool_cmd )
        }

        merge_cmd () {
                ( eval $merge_tool_cmd )
        }
}

即 eval将您的工具命令放在子外壳中，这样您就无法以已知工具的方式覆盖所有内容。

递归合并


当Git需要执行递归合并时...


在这一点上，这个问题大部分都是有争议的。合并工具根本不会遇到这种情况，因为 git mergetool是在Git本身完成递归合并并将结果保留在索引和工作树之后调用的。但是，合并驱动程序确实在这里有发言权。

当 -s recursive合并策略合并合并基础以进行新的“虚拟提交”时，它会在合并基础提交上调用另一个 git merge（更准确地说，只是递归地调用自身）（但请参见下文）。内部的 git merge知道它是递归调用的，因此当要应用 .gitattributes合并驱动程序时，它将在其中检查 recursive =设置。这确定是再次使用合并驱动程序，还是将其他合并驱动程序用于内部合并。对于内置的合并驱动程序，Git关闭扩展策略选项，即 -X ours和 -X theirs均无效。

内部合并完成后，其结果（不是内部递归合并的结果，就是所有留在工作树中的文件）实际上都保存为真正的提交。即使存在未解决的冲突，也是如此。这些未解决的冲突甚至可能包含冲突标记。但是，这是新的“虚拟合并基础”提交，它是真实的提交；它只是没有外部名称，您可以通过它找到其提交哈希。

如果在此特定级别有三个或更多合并基础，而不仅仅是两个合并基础，则此新的虚拟合并基础现在将与下一个剩余的合并基础进行迭代合并。逻辑上，Git可以在这里使用分而治之的策略：如果最初有32个合并库，它可以一次将两个合并库合并以产生16个提交，一次合并两个库合并以产生8个提交，依此类推。但是，除了进行ceil（log2（N））合并而不是N-1合并外，尚不清楚这样做是否会带来很多好处：N> 1已经非常罕见。