git merge -s recursive -X我们vs git merge -s我们的？

Question

在man git-merge doc中,git merge -s recursive -X ours:

这不应该与我们的合并策略混淆,后者甚至不会查看其他树包含的内容.它丢弃了另一棵树所做的一切,宣告我们的历史包含了其中发生的一切.

我测试过这两个但是找不到差别.

有一个例子可以说明这两者之间的区别是什么？

我的git版本是 git version 1.8.3.4

Answer 1

正如手册页所说,完全-s ours忽略了另一个分支的内容.这应该足够明显了:无论另一个分支中的内容是什么,附加到合并提交的树HEAD与合并之前的提交中的树相同.

什么-X ours是更微妙的:它只在发生冲突时使用"我们的"版本的变更.

这是一个相对简单的例子.

假设您在分支机构br1并且要求合并分支机构br2.我们会让这些非常简单,与提交B(合并基地产地为两个分支),具有一个单一提交K分支br1,和一个单一提交L的分支br2:

... - B - K   <-- HEAD=br1
        \
          L   <-- br2

此外,从差B到K只包含一个项目:

同时,从差B到L包括:

当你没有策略或选项合并它们时,文件中会发生冲突f1(对相同行的不同更改),但不会f2(在合并提交中会对提交进行更改以L使文件f2发生更改).

如果您使用:

git merge -s ours br2

merge命令将使用"我们的"文件版本f1(dog变为cat),以及我们的文件版本f2(elephant未更改).

如果您使用:

git merge -s recursive -X ours

merge命令会在文件中找到冲突f1并将解析它以支持我们的版本 - 这与之前相同 - 但文件没有冲突f2,因此git将使用它们的版本f2(elephant变为rhinoceros).

(这个简单的例子没有说明如果在f1or 中的不同区域中存在两个不同的更改会发生什么f2.如果f1足够长并且提交的L进一步变化比"文件的第一行"更低,则合并可以获取该变化因为它不会与冲突dog-到- cat的变化.)

Answer 2

我不知道任何具体的例子,但区别在于:

git merge -s recursive -X ours

这会进行"正常"合并(recursive策略是默认策略),当发现冲突时,它会尝试通过自动使用合并到的分支中的代码片段("我们的")来解决这些冲突,而不是离开冲突标记.

git merge -s ours

正如你引用的文档所说,这需要我们完整的代码版本,并使其成为合并的结果 - 其他分支甚至没有被查看,没有检测到冲突等等.它只是简单地说"make一个新的提交看起来像是合并了另一个分支,但是将结果内容完全保留在它当前在当前分支中的样式".