Git merge 会“重播”更改，但真的是这样吗？

Question

git merge 文档说明了该示例：

      A---B---C topic
     /
D---E---F---G master

然后“git merge topic”将重放主题分支上所做的更改，因为它从master分支（即E）直到其当前提交（C）位于master之上，并将结果与​​名称一起记录在新的提交中两个父提交以及来自用户的描述更改的日志消息。

我想知道“重放更改”这个短语。在其他关于 git 合并的文章中我几乎找不到提到“重播”这个词。

我想象 git 找到 A 和合并基础之间发生的变化，应用该更改，应用 B 和 A 之间的差异，应用 C 和 B 之间的差异，然后将这一系列更改合并到合并提交中。本质上是查看合并基础后的每个提交并单独评估它们。

如果这是真的，那么会发生什么……

      A---B---C---I topic
     /         \
D---E---F---G---H(merge)---O master

我想将 master 合并到 topic 中。假设当前分支是主题“ git merge master ”。我的“ git merge-base master topic ”合并基础是提交C。

如果我们坚持“重播”更改的故事，主题分支如何获取提交 F 和 G 的更改？它是否找到了 H 和 C（合并基础）之间的差异？如果是这样，为什么要重播第一个示例中的一系列更改，而只是查找分支头和合并基础之间的差异？

Answer 1

我认为“重播”这个词是个糟糕的术语：

\n\n

\n

我想象 git 找到 A 和合并基础之间发生的变化，应用该更改，应用 B 和 A 之间的差异，应用 C 和 B 之间的差异，然后将这一系列更改合并到合并提交中。

\n

\n\n

这将是解释该措辞的合理方式。

\n\n

Git 不是这么做的。

\n\n

结论：措辞不佳。

\n\n

Git所做的就是找到合并基数¹，然后计算该提交与要合并的两个^{2提交的差异，每个此类提交都有一个差异。}这些差异有效地“跳过”所有中间工作。

\n\n\n\n

¹假设图中只有一个最低共同祖先。如果有多个 LCA 候选者，下一步取决于合并策略。

\n\n

（默认）策略-s recursive通过合并多个合并基础（两个或多个 LCA）并进行新的临时提交来处理它们。它通过递归调用自身来进行合并，因此称为“递归”。该-s resolve策略通过任意选择一个合并基础并像只有一个合并基础一样继续处理来处理多个合并基础。

\n\n

²实际上是两个或更多，除非只有某些合并策略可以处理两个以上的头。具体来说，该-s ours策略可以使用任意数量的头\xe2\x80\x94，但它会忽略除当前头之外的所有头，这意味着它会进行合并提交（作为名词/形容词合并），而不执行任何合并工作（作为动词合并） ）。该-s octopus策略还可以处理两个以上的头，但在其他方面比双头策略受到更多限制。

\n