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

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

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

用户发出git merge命令。

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

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

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

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

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

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

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

现在，我们处于一个合并基本提交 B ，两个提交 L （本地或左侧，--ours）和 R
（远程或右侧，--theirs）的阶段。现在，这两种常规策略（-s recursive和-s resolve）在git diff --name-status启用重命名检测的情况下执行了一对操作，以查看 B- to- L 更改中是否存在更改其名称的文件，以及 B- to-
R中 是否存在文件。改变，改变他们的名字。这也发现是否有任何新添加的文件 大号 或 [R ，而如果文件在删除任何 大号 或 [R
。所有这些信息被组合以产生 文件身份 ，因此Git知道要组合哪些更改集。这里可能存在冲突：例如，文件的路径在基础中为 P B，但现在同时为 P
L_和 _P R，则具有重命名/重命名冲突。

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

下一步非常关键，这就是索引进入图片的位置。这三个斑点对象的散列ID的是H 乙，H 大号和H [R
。GIT中分别准备好放置这三个散列到索引，在时隙1，2和3，但现在使用中所描述的规则的git read- tree下3路合并部分文档：

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

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

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

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

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

内置文件合并直接从索引开始（尽管如果要通过索引运行它，git merge- file则必须将blob提取到文件系统中）。它提取文件，执行其操作以合并它们，并视情况（取决于扩展策略选项）-X ours或-X theirs写入冲突标记。它将最终结果放入Git选择用作最终路径名的任何路径名下的工作树中，并完成操作。

• 使用合并驱动程序（通过.gitattributes）。合并驱动程序使用arguments运行。但是，这些参数是通过让Git 将三个Blob对象 提取 到三个临时文件来构造的。

该参数从无论我们把尽可能扩大%O，%A，%B，%L，和%P。这些自变量字母与我们一直在使用的字母不太匹配：%O是 基础
文件%A的名称，是左侧/本地/ --ours版本%B的名称，是右侧/ other /远程/
--theirs版本的名称，%L是conflict-marker- size设置（默认值为7），%P是Git用来将最终结果保存在工作树中的路径。

需要注意的是%O，%A和%B是所有的名字 暂时
了Git创建（持有BLOB内容）的文件。他们都不匹配%P。Git希望合并驱动程序将合并结果留在路径中%A（然后Git会%P自行将其重命名为）。

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

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

使用 git mergetool

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

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

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

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

$ 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本身完成递归合并并将结果保留在索引和工作树中 之后git mergetool会调用合并工具。但是，合并 驱动程序 确实在这里有发言权。

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

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

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