为什么git rebase的合并冲突比merge更少？ [英] Why does git rebase often have fewer merge conflicts than a merge?

问题描述

我经常听说它说使用git rebase减少了合并冲突的数量，而不是git merge，但我从来没有找到解释为什么会这样的情况。

只要在另一组更改上重播一组更改，当两个人都修改相同的代码行时，不会奇迹般地消除内在的冲突，更好的？

任何人都可以提供一个简单的例子，其中合并会产生冲突，但rebase不会？

<更新：经过3年多的Git经验后，我开始相信我的原始前提是错误的：在重组与合并中冲突同样可能发生。然而，Rebase确实可以让历史更容易理解，并在需要时进行选择或回滚。

解决方案

他们会被引入，所以实际上你没有任何东西。

如果我在我的特性分支中编辑了一条线，并做一个简单的合并，它会发生冲突。

如果我重新绑定，它会停止在我做出这一更改的提交，并在那一点处理冲突。

I've often heard it said that using git rebase reduces the number of merge conflicts as opposed to git merge, but I've never found an explanation of why this is the case.

Simply replaying one set of changes on top of another set of changes doesn't magically dispel the inherent conflict when two people both modify the same line of code, so what makes rebase better?

Can anyone provide a simple example where a merge would have conflicts but a rebase doesn't?

UPDATE: After 3 additional years of git experience, I've come to believe that my original premise was false: conflicts are equally likely in rebase vs merge. Rebase does however make history easier to comprehend and cherry-pick or rewind when needed.

解决方案

You resolve the conflicts in the commit where they would have been introduced, so in effect, you don't have any.

If I edit a line in my feature branch which has since changed in the master branch, and do a straightforward merge, it will conflict.

If I rebase, it will stop at the commit where I made this change and at that point I deal with the conflict.

这篇关于为什么git rebase的合并冲突比merge更少？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！