用实例理解重基冲突与合并冲突

Question

我正在尝试找出一个示例，其中重基冲突是，与合并冲突不同的。

我明白个别术语--重新定位和合并--意味着什么。但我不太明白他们怎么会制造不同的冲突。

有人能给我举个例子指出正确的方向吗？

Answer 1

下面是一个简单的、有点做作的例子。假设您根据这个图表从主分支中分离出来：

main:   .. A -- D
            \
feature:     B -- C

并且在某个源代码文件中有一个函数：

function foo() {
    int a = 3;
    return a;
}

假设出于任何原因，您决定在commit B中添加一行：

function foo() {
    int a = 3;
    int b = 10;
    return a;
}

在第二个提交C中，您删除了添加的行，保留了从主分支中分支时的代码。

同时，在主分支中，其他人现在已经做了一个新的提交D，它还添加了一个新行：

function foo() {
    int a = 3;
    int c = 5;
    return a;
}

如果要在主分支上重新设置功能分支，代码将从D提交中的int c = 5行开始。但是，重新应用您的第一个B提交将产生合并冲突，因为两个家长都试图在相同的函数中向相同的位置添加一个新行。您将解决该冲突，然后选择您想要的任何版本。

但是，如果要将主分支合并到分支中，则不会发生冲突。原因是您的特性分支是从C提交开始的，C提交的源代码与主分支中的A提交相同。因此，只有一个函数的变化会发生，来自主分支，并且很可能没有冲突。

合并冲突与合并冲突的经验法则是，通常情况下，它们可能不一样。将您的工作(提交)重新部署到一个新的基础之上，每次重新提交都会导致合并冲突。另一方面，合并会在目标分支中同时引入一个增量。

Answer 2

在实践中，冲突差异通常产生于这样一个事实，即重基一次只应用一个提交修补程序，而合并只查看每个分支的最终状态(以及合并基--分支的最后一个提交)。

所以如果你有

o --- x <--(master)
 \         
  A - B - C  <-(feature)

并且希望将feature与master结合起来，也许o-A修补程序与o-x冲突，尽管o-C补丁没有--在最简单的情况下是因为B或C取消了A所做的事情。然后，重基将产生合并不会产生的冲突。

此外，您可能在重基期间解决A的冲突，并且在应用B和C时更改重基的过程。这有点难以想象，因为这取决于您如何编辑工作树在重新部署冲突解决，但从理论上说，这是可能的。

此外，与重基相比，合并可能导致不同的最终内容。我想您可以将这些场景操作为冲突不同的情况。

内容为何不同？当然，它不应该出现，而且在我看来，这些案例都是奇怪的边缘案例，在我看来，这是因为rebase过于努力地试图变得聪明--但不管它们在实践中几乎从未出现过。