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的作用更为微妙：它使用＆＃34;我们的＆＃34;只有在发生冲突时更改的版本。

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

假设您已经在分支br1上并要求在分支br2中合并。我们将这些变得非常简单，使用commit B（两个分支的合并基源）在分支K上有一个提交br1，并且一个提交{{1在分支L上：

br2

此外，从... - B - K <-- HEAD=br1 \ L <-- br2 到B的差异只包含一项：

• 更改（现有）文件K：将第一行f1替换为dog

同时，cat与B之间的差异包括：

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

当您合并这些没有策略或选项时，文件rhinoceros中会发生冲突（对相同行的不同更改），但f1中不会发生冲突（合并提交将进行更改）在提交f2中，以便文件L会改变。）

如果您使用：

f2

merge命令将使用＆＃34;我们的＆＃34;文件版本git merge -s ours br2 （f1变为dog），以及我们的文件版本cat （f2未更改）

如果您使用：

elephant

merge命令会在文件git merge -s recursive -X ours 上发现冲突并将解析它以支持我们的版本 - 这与以前相同 - 但文件f1上没有冲突，所以git将使用他们的f2 版本（f2变为elephant）。

（这个简单的示例并未显示如果rhinoceros或f1中的不同区域有两个不同的更改，会发生什么。如果f2足够长并且有更改在提交f1进一步低于＆＃34;文件的第一行＆＃34;，合并可以获取该更改，因为它不会与L - to- {发生冲突{1}}改变。）

Answer 2

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

git merge -s recursive -X ours

这是正常的＆＃34;合并（recursive策略是默认策略），当发现冲突时，它会尝试通过自动使用合并到的分支中的代码片段来解决这些冲突（＆＃ 34;我们的＆＃34;），而不是留下冲突标记。

git merge -s ours

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