‘`rebase’导致的冲突比‘`merge’少，这是真的吗？

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’
• take、G’
• take和F‣F’，以及如何将它们组合成H’

、G‣H和G‣G’。

因此，rebasing完全等同于将F、G和H合并到top-branch中。

那么，这对冲突意味着什么呢？

rebase方法将在更多的步骤中完成合并。这有好处也有坏处。

Rebase > Merge：

通过在较小(更分离)的步骤中应用更改，可以避免

• 冲突。
• 执行rebase的人员正在逐个应用(可能)他自己的更改，并解决其中的冲突。解决冲突可能比一次解决所有冲突更容易。

Merge > Rebase

使用rebase时，您必须解决更多冲突的风险很高，因为在两次不同的提交中对同一代码块进行的两次更改可能会在rebase期间导致两个冲突，但在

• 中只有一个冲突。想一想当合并实际上是F.

• Even的还原时会发生什么如果你有相同数量的冲突，重新建立基址仍然是一个更乏味的过程:你必须多次打开同一个文件来解决在不同commits.

• Resolving发生的冲突实际上使用H可能会更容易，因为你可以同时看到两个分支的所有更改。

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

Answer 2

rebase的一个优点是，您可以根据总提交、稳定、提交解决方案的一部分进行rebase，现在您有了一个可以在以后恢复的原子进度单元。这可能不那么令人望而生畏。事实上，您可以重新设置一些基础，然后合并其余的。更灵活。