为什么我的 Git 合并中会出现冲突？答案

【问题标题】：Why do I get conflicts in my Git merge?为什么我的 Git 合并中会出现冲突？
【发布时间】：2014-01-20 15:33:29
【问题描述】：

当只有一个发生更改时，我在两个本地分支之间的合并中遇到冲突。更糟糕的是，冲突标记毫无意义。这种情况现在已经发生了两次。谁能告诉我这里发生了什么，以及如何避免它？

看起来好像合并是在比较文件的左右版本与基本版本，而不是相互比较。我在一段时间没有改变的东西上发生冲突。

详情

回购。有两个分支，“master”和“dev”。工作流程是这样运行的：

创建了新的存储库。并手动复制到现有代码中。
git checkout -b dev
[一堆提交。]
git checkout master; git commit --squash dev
手动将代码复制到我们的发布过程中。
时间流逝；向 master 提交了一些提交以修复小错误。
git checkout dev; git merge master

此时问题开始了。

首先：我遇到了合并冲突。这对我来说毫无意义；唯一的变化是在“主人”中。三路合并应该已经解决了。

我认为使用 commit --squash 使合并的基本文件比其他情况要旧得多，但我已经手动比较了所有三个版本的文件，但我仍然没有没看到。大多数标记的更改是基础中缺少的部分，但在左右版本中是相同的。合并不应该认为没有变化吗？

其次：我拥有的合并标记已损坏。来自左侧版本的部分与来自右侧版本的部分不匹配。这正常吗？

一些示例代码。这里唯一的实际变化是添加了def buffer b-product for product. 行（请参阅“SKU Missing”代码如何在第一个冲突块的左侧块中，但在 第二个的右侧块中 冲突块？）：

<<<<<<< HEAD
    if not avail b-orddet
    then
        {&throw} ("No gapnet-orddet record", 300).

    op-errorred = no.

    /** SKU missing **/
    if b-orddet.sku = ?
    or b-orddet.sku = ""
    then
    do:
        run make_report_line
            ( input b-orddet.order-num,
              input b-orddet.line-no,
              input "e",
              input "SKU not set" ).

        op-errorred = yes.
    end.
=======
    def buffer b-product for product.

    if not avail b-orddet
    then
        {&throw} ("No gapnet-orddet record", 300).
>>>>>>> master

    op-errorred = no.

<<<<<<< HEAD
    /** SKU doesn't match an Accord product **/
    if not can-find( product
               where product.p-code = b-orddet.sku )
    then
    do:
=======
    /** SKU missing **/
    if b-orddet.sku = ?
    or b-orddet.sku = ""
    then
    do:
        run make_report_line
            ( input b-orddet.order-num,
              input b-orddet.line-no,
              input "e",
              input "SKU not set" ).

        op-errorred = yes.
    end.

    find b-product
        where b-product.p-code = b-orddet.sku
        no-lock no-error.

    /** SKU doesn't match an Accord product **/
    if not avail b-product
    then
    do:
>>>>>>> master

【问题讨论】：

看来git merge -s recursive -X theirs 的行为很正常，正如我所预料的那样。这很好，但我怎么知道我什么时候需要这样做？
如果您将merge.conflictstyle 设置为diff3，您将获得<<< original ||| base === new >>> 的序列，这通常更容易理解为什么git 的合并选择了它所做的事情。有时这是因为基本版本与其他两个版本差异太大，导致错误同步......在这种情况下，有时打开patience 据说会有所帮助；另见--diff-algorithm=。
git merge -Xignore-all-space 或 git merge -Xignore-space-change ??
@Torek: --patience 和 --diff-algorithm 是git diff 上的选项，而不是git merge？你的意思是我要尝试什么？
git merge 有 -X 将选项传递给所选策略。 -X patience 开启 diff 耐心，-X diff-algorithm= 允许你指定 diff 算法（所以 -X patience 等于 -X diff-algorithm=patience，大概）。

标签： git merge merge-conflict-resolution

【解决方案1】：

如果你想从master合并到branch

git fetch origin/branch
git reset --hard origin/branch
git pull
git merge master

【讨论】：

不，我不知道。如需更多信息，请阅读问题。