什么是内联合并时的变基

Question

我正在阅读关于git rebase的{​​{3}}，其中包含以下段落：

  

默认情况下，rebase将内联合并。我们现在确保我们的   合并在我们的历史图中有明确的语义，这个内联是   真实的无赖......

     

我们可以通过告诉我们要保留的rebase来避免这种情况   合并：我们需要做的就是用--preserve-merges（或者{。}}调用它   简写-p）

我不明白内联的含义。能否请您提供一个精心设计的示例，以便我明白这一点？

Answer 1

来自git-scm doc

  

假设存在以下历史记录，并且当前分支是“主题”：

      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主题将是：

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

因此，基础rebase上的分支topic的{​​{1}}操作将获取所有不在主服务器中的master提交，将当前状态重置为{{1}并逐个重放这些提交（要求用户处理一路上的不一致，这解释了提交topic，master ...可能与A' {不同{1}} ..）。

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

一开始，您有一个本地B'，它是主服务器和分支A之间的合并提交。然后，用户使用rebase（B）进行拉动，这相当于master上的折扣分支origin/feature。在该阶段，git pull -rebase中不在master中的所有提交都是origin/master的合并分支祖先中的提交，即提交中的提交master。问题是重放那些提交会消除那些曾经在origin/master中碰巧合并的外部分支的事实。

也就是说，master就是你要问的origin/feature。虽然为常规分支（上面的doc中的示例）做这样的事情可能没问题，但是如果它是用来跟踪这些提交的来源（如文章中的那样），那么合并信息就会出现问题。链接到）。