git rebase是否比git merge创建更多的冲突？

Question

听说git rebase比git merge更容易产生冲突，这是真的吗？我之前听过这种说法，这篇文章也提到了这个问题。

作者只是根据经验进行了推测，但我认为对于git rebase普遍存在的焦虑主要源自两个方面：

1. 由于git rebase的机制，合并冲突更加频繁且似乎更难处理。

作者没有详细说明该说法的原因，但这不是我第一次听到这件事了。

我知道因为rebase逐个提交地重新播放，所以可能会遇到相同的冲突多次，但是我从未遇到过。也许现在git rebase中默认采用了rerere行为？

我正在尝试为我的团队提出一个rebase策略，但如果上述说法准确的话，我想解决这个问题。

老实说，我想预期会有相同数量的冲突，因为对于两个分支的变化，无论是rebase还是merge，最终都会导致冲突。换句话说，冲突不是由分支在结束时汇合造成的，而是由同一行的并行更改造成的。

- Hilikus

Answer 1

如果有多个提交，使用变基会导致更多的冲突。这是因为在变基时，您必须为每个提交解决冲突。这意味着，如果您尝试将一个比您的主分支超前5个提交的分支变基，并且在这5个提交中的第一个提交引入了合并冲突，则您必须在后续每个提交中解决该冲突。

经常进行变基通常可以解决上述问题。此外，值得一提的是，如果您想将多个提交压缩成一个具有描述性消息的提交，则有一种比变基更简单的策略。

假设您有5个提交要合并到主分支中，但只有一个功能可以轻松地用一个具有描述性消息的提交来描述。

git fetch
git merge origin/master
git reset --soft origin/master
git commit

如果您只想要一个单独的提交，这种方式更加简单，并实现了与变基相同的效果。

- Charles Durham

---

只创建一个（非合并）提交的更简单的方法是使用 git merge --squash origin/master 和 git commit。 - sschuberth

你能详细解释一下为什么我需要多次解决冲突吗？比如在我创建分支后，master 分支的第一个提交修改了 foo 文件。而我的分支的第一个提交也修改了 foo 文件，这就会在我将分支合并到 master 时产生冲突。但是如果 master 的第二个提交修改了 bar 文件，而我的分支的第二个提交继续修改 foo 文件，那么为什么我需要再次解决相同的冲突呢？ - Hilikus