Git merge "replays"发生变化，但是呢？

Question

示例的 git merge 文档说明:

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

Then "git merge topic" will replay the changes made on the topic branch since it diverged from master (i.e., E) until its current commit (C) on top of master, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes.

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

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

如果这是真的，那么在...的情况下会发生什么

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

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

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

Answer 1

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

I imagine git finding what changed between A and the merge base, applying that change, applying the diff between B and A, applying the diff between C and B, then consolidating that series of changes into a merge commit.

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

这不是 Git 所做的。

结论:措辞不佳。

Git 做 做的是找到 merge 基础¹，然后计算从该提交到两个² 提交的差异被 merge ，每个这样的提交都有一个差异。这些差异有效地“跳过”了所有中间工作。

---

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

-s 递归(默认)策略通过 merge 它们并进行新的临时提交来处理多个 merge 基础(两个或多个 LCA)。它通过递归调用自身来实现 merge ，因此得名“递归”。 -s resolve 策略通过任意选择一个 merge 基并继续处理多个 merge 基，就好像只有一个 merge 基一样。

²两个或更多，真的，除了只有某些 merge 策略处理两个以上的头。具体来说，-s ours 策略可以使用任意数量的头部——但它会忽略除当前头部以外的所有头部，这意味着它在不进行任何 merge 的情况下进行 merge 提交( merge 为名词/形容词)工作( merge 为动词)。 -s octopus 策略也可以处理两个以上的头，但在其他方面比双头策略更受限制。