什么是基于重置时的内联合并？

Question

我正在阅读有关git rebase的这篇文章，其中包含以下内容：

默认情况下，rebase会将合并内联。由于我们现在确保我们的合并在历史图中具有清晰的语义，因此这种内联是真正令人失望的......

我们可以通过告诉rebase我们想要保留合并来避免这种情况:我们需要做的就是使用--preserve-merges(或简写为-p)调用它

我不理解他所说的“内联”的意思。您能否提供一个详细的示例以便我理解？

- courses.indepth.dev

Answer 1

来自 git-scm文档

Assume the following history exists and the current branch is "topic":

      A---B---C topic
     /
D---E---F---G master From this point, the result of either of the following commands:

git rebase master git rebase master topic would be:

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

因此，在基础分支master上进行的分支topic的rebase操作将采用不在master中的topic所有提交记录，将当前状态重置为master，并逐个回放这些提交记录（要求用户在处理过程中处理不一致性，这就解释了提交记录A'，B'...可能与A、B等不同）。

同样的逻辑也适用于合并分支。正如您文章中显示的图片所示：

一开始，您有一个本地的master分支，它是主分支和origin/feature分支之间的合并提交。然后用户使用rebase进行拉取（git pull -rebase），这相当于在origin/master上对master分支进行rebase操作。在这个阶段，所有不在origin/master中的master分支的提交都来自于master的合并分支祖先，即origin/feature分支中的提交。问题在于，重播这些提交会删除这些曾经外部分支的事实，而这些提交现在已经合并到了master分支中。

也就是说，你问到的“inlining”就是这个“replay”。虽然对于常规的fork（以上文档中的示例）这种做法可能还可以接受，但如果您使用它来跟踪这些提交记录来自哪里（就像您链接到的文章中那样），那么这对于合并信息来说就有问题了。

- Francois G

---

谢谢！所以Git会尝试回放从80b0beb（特性分支中的第一个提交）开始的所有提交，而不仅仅是一个合并提交2e6104b？我假设Git将在主分支上的最后一个提交和分支发生的origin/master提交之间执行git diff，对吗？ - Max Koretskyi

不，它将尝试按时间顺序重放{to-be-rebased}分支中包含但{root-of-rebase}分支中不存在的所有提交，其中第一个提交将是80b0beb。基于git diff的操作在道德上属于“合并”，而不是“变基”——这就是“变基”定义的全部意义所在。 - Francois G

哦，我明白了，谢谢。我读过 Git 使用 git diff 来查找提交之间的差异，然后将其作为重定位的一部分应用（本质上是挑选），所以我不理解你评论中的最后一句话。 - Max Koretskyi

merge = 用于协调事物的单个 git diff。rebase：每个提交使用一个 git diff，以查看它是否存在于 {root-of-rebase} 分支上。当我说“基于 git diff 的操作”时，我应该加粗的重要词是 a。 - Francois G

我在rebase之后没有看到合并提交，是因为它已经在主分支中了吗？ - Max Koretskyi