“rebase”导致的冲突数量是否比“merge”少？

Question

我不时偶然发现“git rebase”导致的冲突数量少于“git merge”的说法，例如这里：为什么 git rebase 通常比合并有更少的合并冲突？. 这是否意味着可能git-merge <BRANCH_A> <BRANCH_B>会出现失败的情况，我会做git reset --hard ORIG_HEAD，然后做，然后git-rebase <BRANCH_B> <BRANCH_A>会成功？你能举一个这种情况的例子吗？

Answer 1

技术差异

想象一下这样的历史：

 A-B-C-D-E  “top-branch”
   \ 
    F-G-H

现在合并 E成H意思是：“采取的DIFFB?H和的差异B?E，并找出如何将它们结合起来”。

重订在另一方面方式：

• 取一个差异B?F和一个差异B?E并找出如何将它们组合成F’
• 取一个差异F?G和一个差异F?F’并找出如何将它们组合成G’
• 取一个差异G?H和一个差异G?G’并找出如何将它们组合成H’

所以 rebase 与 merging F、 thenG和Hinto完全一样top-branch。

现在，这对冲突意味着什么？

rebase 方法将以更多步骤进行合并。这有优点也有缺点。

变基>合并：

• 可以通过在更小（更分离）的步骤中应用更改来避免冲突
• 执行 rebase 的人正在（可能）一一应用他自己的更改并解决其中的冲突。解决冲突可能比一次性解决更容易。

合并 > 变基

• 使用 rebase 时，您必须解决更多冲突的风险很高，因为在两次不同提交中对同一代码块进行的两次更改可能会在 rebase 期间导致两次冲突，但在合并中只会导致一次冲突。想想当H实际上是 的恢复时会发生什么F。
• 即使你有相同数量的冲突，rebase 仍然是一个更乏味的过程：你必须多次打开同一个文件来解决在不同提交中发生的冲突。
• 通过合并解决冲突实际上可能更容易，因为您可以同时看到两个分支的所有更改。

在我看来，rebase 实际上是更糟糕的过程，虽然这可能是可能的，但我很难想象它实际上避免了冲突的情况。似乎很可能是您的冲突仅由F. 当该代码块在 中进一步更改时G，您可能必须将所有这些更改作为合并中的一个冲突来解决，但您只需在 rebase 中解决该一行更改。但这并不是真正的区别，因为冲突只会看起来更大，但应该同样容易解决。