在Git中，如果我将分支B合并到A中并解决合并冲突，那么当再次将A合并到B中时是否仍会发生合并冲突？

Question

我有一个分支Carateristic，如果我尝试将非常类似于integration的分支合并到其中，则会产生大量合并冲突。但是，有人告诉我master本身已经合并到integration中。这是否意味着在将master合并到master时我不应该期望任何合并冲突？

Answer 1

首先，请谨慎使用此一般性概念，它可以产生什么版本控制系统（不仅仅是Git）称为纵横交叉合并：

...--o--o---M   <-- br1
         \ /
          X
         / \
...--o--o---N   <-- br2

从理论上讲，这些从根本上来说不是“错误”，但它们为以后的合并带来了歧义：（有时）不再有单个提交作为以后合并的合并基础，因为合并结果M和N都适合作为合并基础。 （Git针对此问题的标准解决方案，默认为-s recursive，是首先合并合并基础，然后将结果用作两个分支技巧的新合并基础。）

---

您在文本中所说的也许是相反的：

...--o--o--M   <-- master
          / \
...---o--o---N   <-- integration

完全不同，并且与TobiasMende answered一样，Git有时会执行快进而不是合并，除非您禁止它强制进行真正的合并。 （以上图表假设您在git merge --no-ff master上运行integration。）

不幸的是，您在文本中所说的实际上是模棱两可的：

...--o--o--o   <-- master
       ?
...---o--o   <-- integration
          \
           \
            M   <-- [proposed merge that gets conflicts]
           /
          /
...---o--o   <-- thirdbranch

这里问号覆盖了以下语句：有人告诉我integration本身已合并到master 中。我们不知道这是否正确，并且 是正确的，我们不知道在什么时候，也不知道此合并的合并基础在哪里。 thirdbranch标签覆盖短语：与master 非常相似的分支。我们不知道如何相似，或在其上提交什么内容，或者在那个分支与master和/或{{ 1}}。

确定合并的进行方式需要了解：

• 在提交图中（或至少是它在哪个提交中）合并基础所在的位置；和
• 两个分支提示的提交是什么。

Git将对合并基进行两次比较：一次针对当前（HEAD）提交分支提示，以查看自合并基础以来您发生了什么变化，然后对另一个分支提示进行第二次比较，了解自合并基础以来它们发生了什么变化。然后，Git 组合这两组更改，将其应用于合并基础中的文件。将合并的更改应用于合并基础将产生合并结果（作为树）。然后，Git进行新的 merge commit ，将两个合并提示作为合并提交的两个父项。

合并结果取决于合并基础和这两个差异。

Answer 2

是的，没错。如果您已将integration合并到master中，则以另一种方式合并只是快速合并。因此，integration 分支指针可以仅移到合并提交上，因此master和integration指向同一提交。

仅当两个合并之间的这些分支之一上没有更多提交时，这才成立。否则，可能会发生新的合并冲突。

但是您不能从中得出类似于master 的分支的任何假设。