26

我正在与merge.conflictStyleset to合并diff3。通常，这会插入由四 (4) 组字符分隔的三 (3) 个部分。

合并的Git 文档清楚地解释了这些符号对于简单案例的含义（如下所述）。

常规 diff3：

Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
|||||||
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

但是，我得到了一个更复杂的结果，其中包含许多额外的行（见下文）。我有一种感觉，这与我在当前正在合并的提交的祖先中进行了多次合并这一事实有关，但我无法弄清楚额外行的含义。我似乎也找不到任何有关此行为的文档。

这是我得到的（当然是经过编辑的，以保护代码的身份）。

（我试图合并的任何提交的代码中都没有冲突标记，所以这不是答案。）

<<<<<<< ours
||||||| base
<<<<<<< Temporary merge branch 1
||||||| merged common ancestors
        if (sendRedirect(result))
            return new Result("redirect");

=======

        if ( result.getId() != null )
        {   
            object = new SomeObject(searchResult.getId()) ;
        }

        if (sendRedirect(result)){
            return new Result("redirect");
        }

>>>>>>> Temporary merge branch 2
=======

        if ( result.getId() != null )
        {   
            object = new SomeObject(searchResult.getId()) ;
        }

>>>>>>> theirs

我相信这个问题是在问同样的问题，但答案并没有解释它与 diff3 有关的任何其他内容，提问者已经在标题中指出这是他/她熟悉的东西。我尝试编辑该问题两次，但都被拒绝了，所以我再问一次。

4

1 回答 1

21

您在这里所拥有的（Temporary merge branch 1与 2 相同）是由于 git 的“递归合并”方法：

            o->branch1 = "Temporary merge branch 1";
            o->branch2 = "Temporary merge branch 2";
            merge_recursive(o, merged_common_ancestors, iter->item,
                            NULL, &merged_common_ancestors);

( merge-recursive.c，大约在 1940 行)。当提交图有多个合并库的候选者时，Git 将执行递归合并（有关更多信息，请参阅此博客文章）。为了（过度？）简化一点，git 进行了内部递归合并，产生了合并冲突，然后进行了外部合并并遇到了另一个合并冲突。您看到的是外部合并冲突 ( oursvs theirs)，内部冲突显示为“基本”版本。

您可能会发现通过选择其他一些合并策略或使用替代的 diff 算法（与默认的 、 和算法相比patience）minimal可以获得更好的结果。或者，您可能想暂时禁用样式，以便您根本看不到内部合并。histogrammyersdiff3

于 2015-07-13T20:41:02.150 回答