变基时什么是内联合并

what is inlining merges when rebasing

我正在阅读 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)

我不明白他说的内联是什么意思。你能提供一个详尽的例子让我明白吗?

来自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 操作获取不在 master 中的 topic 的所有提交,将当前状态重置为 master,并逐一重放这些提交(要求用户处理一路上的不一致,这解释了提交 A'B' ... 可能不同于 A B ..).

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

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

也就是说,这个 replay 就是您要问的 inlining。虽然对于常规分叉(上面文档中的示例)做这种事情可能没问题,但如果合并信息是您用来跟踪这些提交来自何处的信息(如您在文章中所述) link 到).