Git合併「重播」更改，但是呢？

Question

該示例的混帳合併文檔狀態：

 A---B---C topic 
    /
D---E---F---G master 

然後「混帳合併主題」將重播的話題分支上的修改，因爲它從主（即E）分道揚鑣，直到其當前提交（ C），並將結果與​​兩個父提交的名稱以及來自描述更改的用戶的日誌消息一起記錄在新的提交中。

我在想「重播更改」。在其他關於git合併的文章中，我幾乎找不到「重播」這個詞。

我想git會找到A和合並基礎之間的變化，應用該變化，在B和A之間應用差異，在C和B之間應用差異，然後將這一系列更改合併到合併提交中。基本上在合併基礎之後查看每個提交併單獨評估它們。

如果這是真的，什麼情況下會發生......

 A---B---C---I topic 
    /  \ 
D---E---F---G---H(merge)---O master 

，我想主合併成話題。假設當前分支是主題，「git merge master」。我的合併基數爲「git merge-base master topic」is commit C。

如果我們堅持「重放」更改的故事，主題分支如何獲得提交F和G的更改？它是否找到H和C（合併基礎）之間的差異？如果是這樣，爲什麼要重播第一個示例中的一系列更改，而不是找到分支頭和合並基礎之間的差異？

Answer 1

我認爲這個詞「重放」很差術語：

我想象的git查找和合並基礎之間發生了什麼變化，應用這一變化，應用B和A之間的差異，應用之間的差異C和B，然後將這一系列更改合併到一個合併提交中。

這將是一個合理的方式來解釋的措辭。

這不是Git所做的。

結論：措辭很差。

什麼混帳確實做的是找到了合併基礎，然後計算的diff從提交到兩個提交將被合併，對每個這樣的一個差異承諾。這些差異有效地「跳過」了所有的中間工作。

---

假設有圖中的一個單一的最低共同祖先，即得。如果有多個LCA候選人，下一步取決於合併策略。

-s recursive（默認）策略通過合併它們並進行新的臨時提交來處理多個合併基礎（兩個或多個LCA）。它通過遞歸調用自身來合併，因此名稱爲「遞歸」。策略通過任意選擇一個合併基礎處理多個合併基礎，並且如同僅存在一個合併基礎一樣進行處理。

兩個或更多，真的，除了只有某些合併策略處理兩個以上的頭。具體來說，-s ours策略可以使用任意數量的頭像，但它會忽略除當前頭像以外的所有頭像，這意味着它會進行合併提交（合併爲名詞/形容詞），而不執行任何合併工作（合併爲動詞）。策略也可以處理兩個以上的負責人，但在其他方面比雙頭策略更有限。

Answer 2

他們在這裏使用的描述只是：描述性。但是，真的，沒有什麼不對。

從技術上講，git正好看着三個提交：「我們」，「他們」和「合併基地」。合併基礎和「他們的」之間的變化適用於「我們」，只要它們不與合併基礎和「我們」之間的任何變化相沖突。該文檔將此描述爲「重放」更改。這並不意味着每次提交都會被檢查（一個la 變更）。

從這個角度來看，你的第二例子是非常簡單的：鹼爲C，「他們的」是H，計算和這些變化被施加（「重放的」）以IC和H之間的差異。