Git合并 - 同时合并2个分支会发生什么

Question

我对git的合并有一个不清楚的理解，这是我想正确理解的。

假设我在主分支上有一个文件F，它已经有100个LOC了。我从主人创建了一个分支A，并且我写了50个LOC，从第101行开始到第150行。我创建合并请求合并分支A到主。因此，如果分支A将被合并，则主文件F将具有150个LOC。假设分支A未被合并为主，但仍在等待。我从主人创建一个新的分支B.我也写了50 LOC，也从101行开始到150行（因为分支A还没有合并）。我也创造支路B

一个MR

会发生什么，如果2人2个审查抄表和：

1. 他们在同一时间合并2名女士吗？主人会有冲突吗，因为两个分支想合并成第101到150行？

2. 如果分支A先合并，意味着主设备已经有150 LOC，但分支B仍然从第101行开始到第150行，因为它是在主设备仍然有100 LOC时创建的。 B合并后会有冲突吗？或者Git如何处理这些？

预先感谢（我不是一个巨魔，只是想弄清楚的东西，以防有些人要举报这个问题）

Answer 1

事情澄清，我认为：冲突与融合策略git本身的概念。 “合并请求”，OTOH，是gitlab的概念（和其他回购主机有类似的概念），但根本没有任何合适的地方。你的问题最好通过谈论git来回答;所以我们只需要知道合并请求是合并操作可能在git中开始的一个工作流程。因此，让我们把你的问题分为两个部分：

顺序梅杰斯

简短的回答：有可能会发生冲突。

是否会有冲突取决于合并策略。我的测试表明，通常会有冲突，因为git会看到第101-150行中的替代变化。由于这两组变更都是增加的，所以我猜想你可以想象这两行代码没有冲突 - 尽管目前还不清楚它们的顺序会进去。您可以使用union合并驱动程序让git尝试执行此操作;请参阅http://kernel.org/pub/software/scm/git/docs/gitattributes.html

您可以通过命令行参数告诉g​​it以不同的方式解析合并，但由于这些方向将应用于整个提交 - 不仅仅是一个文件设置此条件 - 您通常不会想要至。你可以使用.gitattributes来影响git如何合并一个文件，如果事先知道这种方法适合（整个）文件的话。

因此，如何更改merge的行为有很多选项 - 太多而不知道具体的预期结果。但通常情况下，使用默认的合并设置并在发生冲突时解决冲突效果很好，无论如何，以我的经验。

并发梅杰斯

为发生“在同一时间”一单式回购中的两个合并这是不是真的有可能。如果主机提供某种方式直接在托管（origin）仓库中启动合并 - 我实际上并不知道任何人都这样做，但为了争辩 - 然后一个合并必须先完成，另一个合并以合并的结果为起点;所以请参阅上一部分答案。

会发生什么，一个人可以在一个回购进行一个合并，另一个人可以执行其他合并在第二回购，然后可以有冲突时，他们都尝试与远程同步起来。这里是如何可能看：

（请注意，在本例子中，我假设真正合并 - 也就是说，如果你使用no-ff选项会发生什么，合并图表可能比较简单，但结果会。同样尽可能冲突走，如果快进合并被允许。）

所以回购开始了与

  B <--(branch_B) 
     /
x -- x -- O <--(master) 
      \ 
      A <--(branch_A) 

所有的提交包含一个文件。在O该文件有100行。 A和B每个添加50个新行到文件的末尾。

现在爱丽丝合并branch_A，鲍勃合并branch_B，每个在他们的本地回购。所以，Alice有

  B <--(branch_B) 
     /
x -- x -- O -- MA <--(master) 
      \/
      A 
      ^-(branch_A) 

，Bob的

  v-(branch_B) 
      B 
     /\ 
x -- x -- O -- MB <--(master) 
      \  
      A <--(branch_A) 

分享他们的工作，他们将分别尝试push到origin;和merge一样，即使他们试图在同一时刻开始推送，也会在另一个开始之前完成。

所以爱丽丝得到她的推动，origin被更新为看起来就像她的本地。当Bob尝试推送时，他得到一个错误，因为他的master位于origin的master后面（或者，我们可以说，一旦更新了origin/master后，假设有典型的映射）。

因此Bob必须pull（或fetch和merge）才能push。为了更清楚地说明，我们假设他是fetch es。现在他有

 v-(branch_B) 
      B 
     /\ 
x -- x -- O -- MB <--(master) 
      |\ 
      | MA <--(origin/master) 
      |/ 
      A <--(branch_A) 

，并完成pull的作用，他需要合并origin/master为master - 所以即使这个情况归结为先覆盖的“顺序合并”的设想。事实上，如果使用快进合并跟踪相同的场景，那么显然这里需要的“第二次合并”与“第二次合并”完全相同，如果一切都是由一个用户在一个回购中完成的话。