git合并-s递归-X与git合并-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 (两个分支的合并基源)在分支br1上有一个单独的提交K，在分支br2上有一个单独的提交L

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

此外，B与K的区别仅包括一个项目：

• 更改(已经存在)文件f1：用cat替换第一行dog

同时，B与L的区别包括：

• 更改文件f1：将第一行dog替换为poodle
• 更改文件f2：将最后一行elephant替换为rhinoceros

当您在没有策略或选项的情况下合并这些文件时，文件f1 (对相同行的不同更改)将发生冲突，但在f2中则不会发生冲突(合并提交将对提交L进行更改，从而使文件f2发生更改)。

如果你使用：

git merge -s ours br2

合并命令将使用文件f1的" our“版本(dog变成cat)，以及文件f2的版本(elephant没有更改)。

如果你使用：

git merge -s recursive -X ours br2

merge命令将在文件f1上找到冲突，并解决它以支持我们的版本--这和以前一样--但是在文件f2上没有冲突，所以git将使用他们的f2版本(elephant变成rhinoceros)。

(这个简单的示例没有说明如果f1或f2中的不同区域发生了两种不同的变化。如果f1足够长，并且提交L比“文件的第一行”更低，那么合并可以获取更改，因为它不会与dog到cat的更改发生冲突。

我们鼓励您自己做这件事，以便进一步了解，但是如果您想要查看流程的任何部分，这里是一个github回购重新创建这个过程。

Answer 2

我不知道有什么具体的例子，但区别在于：

git merge -s recursive -X ours

这样做可以进行“正常”合并( recursive策略是默认的)，当发现冲突时，它试图通过自动使用被合并到的分支的代码片段来解决这些冲突(“我们的”)，而不是留下冲突标记。

git merge -s ours

正如您引用的文档所述，这使用了代码的整个版本，并使其成为合并的结果--另一个分支甚至没有被查看，也没有检测到冲突，等等。它只是简单地说：“让新提交看起来像是合并了另一个分支，但将结果内容保持在当前分支中的样子。”