Git merge diff3風格需要解釋

Question

我已經合並了2個分支並且出現了沖突，我需要一些提示，它從它結束的地方開始，等等。我用一些偽造的數據替換了代碼，以便於閱讀和討論。

<<<<<<< HEAD
    aaaaaa
||||||| merged common ancestors
<<<<<<< Temporary merge branch 1
    bbbbbb
=======
    cccccc
>>>>>>> mybranch
    dddddd
<<<<<<< HEAD
    eeeeee
||||||| merged common ancestors
    ffffff
||||||| merged common ancestors
    gggggg
=======
>>>>>>> Temporary merge branch 2
=======
    hhhhhh
>>>>>>> mybranch

Answer 1

您在此示例中看到的內容（使用Temporary merge branch標記）是diff3與縱橫交錯合並沖突的結果。 我將用一系列定義來解釋這一點。

定義

• merge base ：最近兩個合並分支的提交。 發生合並沖突時，對兩個分支中的相同行進行了不同的更改。 合並基礎包含在任一分支更改它們之前這些行的內容。
• 合並共同的祖先 ：diff3輸出一個額外的“中間”部分，顯示合並基礎中的行 。 這是兩個分支的起點。
• 交叉融合 ：一種合並歷史，其中兩個分支以一種不可能是快速合並的方式相互合並。 我舉一個例子如下。 在縱橫交錯的情況下，有多個合並基礎 。
• 臨時合並分支 ：當存在多個合並基礎時 ，diff3嘗試將它們合並在一起（使用臨時合並分支）以形成在diff3的中間部分中顯示的單個共同祖先 。 當沒有沖突時，這可以無縫地工作，但是當存在沖突時，您會在中間合並的共同祖先部分中看到臨時合並分支的沖突標記。

示例縱橫交叉合並沖突場景

只要兩個分支在不同的時間點彼此合並，就會發生縱橫交錯。

m3 *
   |\
   | \
   |  * B1
   |  |
m2 *  * B0
   |\/|
   |/\|
m1 *  * A
   | /
   |/
m0 *

考慮這一系列事件：

• m0作為origin / m aster存在
• 我創建了一個功能分支feature-A ，其中一個提交A
• m1由其他人承諾掌握
• 我啟動了一個基於A的新功能分支feature-B
• 我將origin/master （ m1 ）合並到feature-B 。 它沖突，我解決它。 合並提交是B0 。
• 我實現了功能-B並將工作提交為B1 。
• feature-A已准備好發貨，因此有人將其合並為master 。 它有沖突。 他們解決了它，但它們的分辨率與B0的分辨率不同。 合並提交是m2 。
• feature-B已准備好發貨，因此有人將其合並為master 。 git嘗試確定合並基數 ，但m1和A都兼容合並基礎。 git在臨時合並分支中合並m1和A ，這會導致沖突。 我們在合並的共同祖先部分看到diff3輸出，類似於OP的問題。

讀取輸出

關閉diff3，這個合並沖突看起來就像這樣：

<<<<<<< HEAD
    aaaaaa
=======
    hhhhhh
>>>>>>> mybranch

首先，使用所有額外的標記，您將需要確定實際的沖突線是什么，因此您可以將它與diff3共同祖先輸出區分開來。

aaaaaahhhhhh，那好一點。 ;-)

在兩個沖突的決議是矛盾的情況下， aaaaaa和hhhhhh是兩項決議。

接下來，檢查合並的共同祖先的內容。

有了這個特定的合並歷史，有超過2個合並基礎，這需要多個臨時合並分支，然后合並在一起。 當存在許多合並基礎和沖突時，結果可能變得非常毛茸茸且難以閱讀。 有人說不要打擾，只是為這些情況關閉diff3。

還要注意git內部可能決定使用不同的合並策略來自動解決沖突，因此輸出很難理解。 如果可以，請理解它，但要知道它不是供人類消費的。 在這種情況下，將mybranch合並到bbbbbb和cccccc之間的Temporary merge branch 1時發生沖突。 行dddddd在臨時合並分支之間沒有沖突。 然后在將Temporary merge branch 2到具有多個共同祖先的HEAD時發生單獨的沖突。 HEAD通過將ffffff和gggggg合並為eeeeee解決了沖突，但Temporary merge branch 2通過刪除（或移動）線來解決相同的沖突（因此在======和Temporary merge branch 2之間沒有線。

你如何解決這樣的沖突？ 雖然技術分析是可能的，但您最安全的選擇通常是回過頭來查看沖突周圍所有相關分支的歷史記錄，並根據您的理解手動制定分辨率。

避免這一切

這些沖突是最糟糕的，但有一些行為將有助於防止它們。

1. 避免縱橫交錯合並 。 在上面的示例中， feature-B將origin/master合並為B0 。 這種合並可能與主人保持同步是不必要的（雖然有時候是這樣）。 如果origin/master從未合並到feature-B ，那么就沒有合並縱橫交錯，並且m3將與A作為唯一的合並基礎發生正常沖突。

    m3 * m3 * |\\ |\\ | \\ | \\ | * B1 | * B1 | | | | m2 * * B0 VS m2 * | |\\/| |\\ | |/\\| | \\| m1 * * A m1 * * A | / | / |/ |/ m0 * m0 * 

2. 與沖突解決方案保持一致 。 在該示例中，僅發生臨時合並基礎沖突，因為m2和B0具有不同的沖突解決方案。 如果他們以相同的方式解決了沖突，那么m3將是一個干凈的合並。 雖然這是一個簡單的縱橫交錯合並應該具有相同的分辨率。 其他情況可能正確地具有不同的分辨率。 當合並點之間有兩個以上的合並基礎和多次提交時，事情變得更加復雜。 也就是說，如果你故意在交叉情況下與沖突解決方案不一致，那么以后會出現令人頭疼的問題。

Answer 2

這是一篇關於git的diff3合並樣式的文章。 它指出很難判斷是否在這種風格中添加或刪除了行。

如果您正在尋找具體信息，我建議您優化您的問題。 很難說出你在問什么。