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 - 所以即使這個情況歸結爲先覆蓋的「順序合併」的設想。事實上，如果使用快進合併跟蹤相同的場景，那麼顯然這裏需要的「第二次合併」與「第二次合併」完全相同，如果一切都是由一個用戶在一個回購中完成的話。