git - rebase 时什么是内联 merge

Question

我正在阅读 this article关于git rebase，里面有一段话:

By default, a rebase will inline merges. As we now make sure our merges have clear semantics in our history graph, this inlining is real bummer...

We can avoid this by telling rebase we want to preserve merges: all we need to do is invoke it with --preserve-merges (or the shorthand -p)

我不明白他说的内联是什么意思。您能否提供一个详尽的示例，以便我理解？

Answer 1

来自git-scm doc

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

因此，分支 topic 在基础 master 上的 rebase 操作获取 topic 的所有提交，这些提交是不在 master 中，将当前状态重置为 master，并逐个重放这些提交(要求用户处理一路上的不一致，这解释了提交 A' , B' ... 可能不同于 A B ..).

同样的逻辑适用于 merge 分支。正如您文章中的图片所示:

开始时，您有一个本地 master，它是 master 和分支 origin/feature 之间的 merge 提交。然后用户使用 rebase (git pull -rebase) 进行 pull ，这相当于在 origin/master 上重新设置分支 master。在那个阶段，master 中不在 origin/master 中的所有提交都是在 master 的merged branch ancestor 中的提交，即origin/feature中的commit。问题在于，重播这些提交会消除这样一个事实，即那些曾经恰好已 merge 到 master 中的外部分支。

也就是说，重播 就是您要询问的内联。虽然对于常规 fork (上面文档中的示例)做这种事情可能没问题，但如果 merge 信息是您用来跟踪这些提交来自何处的信息(如您在文章中所述)链接到)。