git - 为什么 git rebase 忽略 merge 提交？

Question

最近我不得不使用 git rebase master 做一些 rebase 来解决一些 merge 冲突。令我惊讶的是，Git 忽略了 merge 提交，导致很多令人头疼的代码会消失。最终我发现 -p 是我要找的东西，但为什么 git rebase 的默认行为忽略 merge 提交？

Answer 1

任何时候你问一个为什么问题，你都会进入哲学领域，这可能非常棘手。但无论如何我可以提出两个答案(文档支持其中一个，如 padawin's answer 中所示。

首先， rebase 背后的最初想法是，它是个人在 merge 到某种更权威的存储库之前或期间会做的事情。

让我们发明两个玩家，Alice 和 Bob。爱丽丝有 authoritative版本:任何想要最新最好版本软件的人都可以去找 Alice。

在 Alice 的存储库中，有各种开发线:

...--o--o--o--o--o   <-- master
            \
             o--o--o   <-- feature/tall

等等。 Bob 在某个时候克隆了 Alice 的存储库，可能是在这个点:

...--o--o--o   <-- master, origin/master
            \
             o--o--o   <-- origin/feature/tall

在 Alice 添加到她的权威 master 的最后两次提交之前。

然后 Bob 从他的 master 开发了他的功能，feature/short，所以他有:

             A--B   <-- feature/short
            /
...--o--o--o   <-- master, origin/master
            \
             o--o--o   <-- origin/feature/tall

他认为他已准备好将他的结果交付给 Alice。所以他运行 git fetch origin 来获取她的任何更新，现在他有了这个:

             A--B   <-- feature/short
            /
...--o--o--o   <-- master
           |\
           | o--o   <-- origin/master
            \
             o--o--o   <-- origin/feature/tall

他现在可能会更新他自己的 master 以便它指向与他的 origin/master 相同的提交(Alice 当前提示的 master ):

             A--B   <-- feature/short
            /
...--o--o--o--o--o   <-- master, origin/master
            \
             o--o--o   <-- origin/feature/tall

在向 Alice 交付他的 A--B 系列提交之前，他应该确保它们有效。所以他可以 git checkout master && git merge feature/short 产生:

             A---B
            /     \
           |       M   <-- feature/short
           |      /
...--o--o--o--o--o   <-- master, origin/master
            \
             o--o--o   <-- origin/feature/tall

Bob 可以测试 M 并查看它是否有效——所以现在可以安全地将 A 和 B rebase 到 的顶端主人，给予:

           [old commits, no longer in use]
           |
           |       A'-B'  <-- feature/short
           |      /
...--o--o--o--o--o   <-- master, origin/master
            \
             o--o--o   <-- origin/feature/tall

请注意，提交 M 已从重新设置基础的 feature/short 中消失:Bob 现在应该交付新的和改进的 A'-B' 提交给 Alice 的链，Alice 可以选择是 merge 它们，还是快进到 B'，或者她喜欢的任何内容。

这里的第二个想法是实际上不可能复制 merge 提交。将提交 A 复制到 A' 只是做 A 与其父项相比所做的相同更改的问题。将 B 复制到 B' 只是进行与 B 对 A 相同的更改。但是你不能复制 merge ；你必须做一个全新的 merge 。那当然是可能的；这就是旧的 -p 或新奇的 --rebase-merges 实际做的:他们只是识别之前发生 merge 的地方，然后做一个新的——可能如果新的 merge 基础不同，则结果会大不相同——只要有意义。

新 merge 的两个父项之一很明显:它是来自某个原始提交的重新设置副本提交，该提交是原始 merge 的父项。 other 父级——假设是双父级 merge ，无论如何——并不是那么明显:有时它是一个未更改的原始提交，有时它是一个重新设置基数的提交。所以这项工作比一开始看起来要难。旧的非 -p rebase 代码简单地说:这很难，而且在大多数情况下我们根本不想这样做，所以我们不要费心去尝试。

(我认为这是错误的——如果你天真地 rebase 涉及 merge 的链，你可能也想复制 merge ——但与此同时，我认为如果你天真地 rebase 一个涉及 merge 的链，你没有充分考虑你在做什么。所以默认行为有点有意义。如果它检测到要跳过的 merge ，并警告或需要一个标志，它可能更有意义。 )