“rebase”导致的冲突数量少于“合并”吗？

Question

我不时偶然发现一个声明，'git rebase'比'git merge'导致更少的冲突，例如：Why does git rebase often have fewer merge conflicts than a merge?。这是否意味着可能会出现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意味着：“取B‣H的差异和B‣E的差异，并找出如何合并他们。”

另一方面，

重新定位意味着：

• 获取B‣F的差异和B‣E的差异，并了解如何将它们合并到F’
• 获取F‣G的差异和F‣F’的差异，并了解如何将它们合并到G’
• 获取G‣H的差异和G‣G’的差异，并了解如何将它们合并到H’

因此，变基与将F，G和H合并到top-branch完全相同。

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

rebase方法将以更多步骤进行合并。这有利有弊。

Rebase＆gt;合并：

• 通过在较小（更多分开的）步骤
中应用更改，可以避免冲突
• 执行rebase的人正在逐一应用（可能）他自己的更改并解决其中的冲突。解决冲突可能会更容易一次完成。

合并＆gt;变基

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

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

Answer 2

重新定位的一个优点是，您可以对总提交的一部分进行重新定位，稳定，提交解决方案，并且您现在拥有可以在以后恢复的原子进度单位。这可能不那么令人生畏。事实上你可以改变一些然后合并其余的。更灵活。