git merge -s recursive -X ours vs git merge -s ours? [英] git merge -s recursive -X ours vs git merge -s ours?

问题描述

在 man git-merge 文档中，git merge -s recursive -X ours:

In man git-merge doc, git merge -s recursive -X ours:

这不应与我们的合并策略混淆，后者确实甚至根本不看另一棵树包含什么.它丢弃另一棵树所做的一切，宣布我们的历史包含所有这些发生在其中.

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.

我已经测试了这两个，但找不到区别.

I have tested these two but can't found the difference.

有没有例子可以说明这两者之间的区别?

Is there an example to tell what is the difference between these two?

我的git版本是git version 1.8.3.4

推荐答案

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

As the man page says, -s ours ignores the contents of the other branch entirely. This should be obvious enough: no matter what's in the other branch, the tree attached to the merge commit is identical to the tree in the HEAD commit before the merge.

-X ours 所做的更微妙:它只在发生冲突时使用我们的"版本的更改.

What -X ours does is more subtle: it uses "our" version of a change only when there's a conflict.

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

Here's a relatively simple example.

假设您在分支 br1 上并要求在分支 br2 中合并.我们会让这些变得非常简单，提交 B(两个分支的合并基础源)在分支 br1 上有一个单一的提交 K，并且在分支 br2 上一次提交 L:

Suppose that you're on branch br1 and you ask to merge in branch br2. We'll make these really simple, with commit B (the merge base origin for both branches) having one single commit K on branch br1, and one single commit L on branch br2:

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

此外，B 和 K 的区别只包括一项:

Furthermore, the difference from B to K consists of only one item:

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

同时，B 和 L 的区别在于:

Meanwhile, the difference from B to L consists of:

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

• change file f1: replace first line dog with poodle
• change file f2: replace last line elephant with rhinoceros

当你在没有策略或选项的情况下合并这些时，文件f1(同一行的不同更改)会发生冲突，但f2(合并提交会改变提交 L 以便文件 f2 会改变).

When you merge these with no strategy or options, there will be a conflict in file f1 (different changes to the same lines), but not in f2 (the merge commit would take the change in commit L so that file f2 would change).

如果您使用:

git merge -s ours br2

合并命令将使用文件f1的我们的"版本(dog变成cat)，还有我们的版本文件 f2(elephant 没有改变).

the merge command will use "our" version of file f1 (dog becomes cat), and also our version of file f2 (elephant is not changed).

如果您使用:

git merge -s recursive -X ours

merge 命令会发现文件 f1 上的冲突，并将解决它以支持我们的版本——这和以前一样——但文件 f2 上没有冲突code>，所以git将使用他们的f2版本(elephant变成rhinoceros).

the merge command will find a conflict on file f1 and will resolve it in favor of our version—this is the same as before—but there is no conflict on file f2, so git will use their version of f2 (elephant becomes rhinoceros).

(这个简单的例子没有说明如果 f1 或 f2 的不同区域有两个不同的变化会发生什么.如果 f1 是足够长的时间并且在提交 L 比文件的第一行"更远的地方有一个变化，合并可以选择那个变化，因为它不会与 dog-to-cat 改变.)

(This simple example does not show what happens if there are two different changes in different areas in f1 or f2. If f1 is long enough and there's a change in commit L further down than "the first line of the file", the merge can pick up that change since it won't conflict with the dog-to-cat change.)

这篇关于git merge -s recursive -X ours vs git merge -s ours?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！