为什么Git rebase经常比合并少产生合并冲突？

Question

6

我经常听人说使用git rebase相比于git merge可以减少合并冲突的数量，但我从未找到为什么会这样的解释。

简单地将一组更改重放在另一组更改之上并不能奇迹般地消除当两个人都修改同一行代码时的内在冲突，那么是什么使得rebase更好呢？

有没有人能提供一个简单的例子，在这个例子中，合并会产生冲突，但rebase不会呢？

更新：在3年额外的git经验后，我认为我的最初假设是错误的：在rebase和merge中冲突可能性相等。然而，rebase使历史更容易理解，并且在需要时进行cherry-pick或倒回。

- Magnus

1

实际上，rebase 可能会比 merge 产生更多的冲突：考虑两个提交，一个引入了一些冲突的更改，另一个撤销了它。在 rebase 过程中，您将不得不解决一个甚至两个冲突，而合并操作将完全跳过该更改+撤销对。 - Roman

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- bcmcfc · Answer 1

你可以在引入冲突的提交中解决冲突，因此实际上你就没有任何冲突。

如果我在我的特性分支中编辑了一行代码，而这行代码在主分支中已经被修改过，那么进行简单的合并时就会发生冲突。

如果我使用变基，它将停留在我进行更改的提交处，然后我就可以处理冲突。