何時使用不一樣的git merge策略？

在git-merge的手冊頁中，可使用多種合併策略。

• resolve-使用三路合併算法只能解析兩個頭（即當前分支和從中拉出的另外一個分支）。 它試圖仔細檢測縱橫交錯的歧義，而且一般被認爲是安全且快速的。

• 遞歸 -這隻能使用3向合併算法解析兩個磁頭。 當能夠用於三向合併的公共祖先不止一個時，它將建立公共祖先的合併樹，並將其用做三向合併的參考樹。 據報道，經過對來自Linux 2.6內核開發歷史記錄的實際合併提交進行的測試，能夠減小合併衝突，而不會引發錯誤合併。 此外，這能夠檢測和處理涉及重命名的合併。 當拉或合併一個分支時，這是默認的合併策略。

• 章魚 -能夠解決兩個以上的問題，可是拒絕執行須要手動解析的複雜合併。 它主要用於將主題分支頭捆綁在一塊兒。 拉或合併多個分支時，這是默認的合併策略。

• 咱們的 -能夠解析任意數量的頭，可是合併的結果始終是當前分支頭。 它旨在取代側支的舊開發歷史。

• 子樹 -這是一種修改的遞歸策略。 合併樹A和B時，若是B對應於A的子樹，則首先調整B以匹配A的樹結構，而不是讀取相同級別的樹。 對公共祖先樹也進行了此調整。

何時應該指定不一樣於默認值的內容？ 每一個方案最適合什麼狀況？

---

#1樓

「解決」與「遞歸」合併策略

遞歸是當前默認的兩頭策略，可是通過一番搜索，我終於找到了有關「解決」合併策略的信息。

摘自O'Reilly的《 使用Git的版本控制》 （ 亞馬遜 ）（措辭）：

最初，「解決」是Git合併的默認策略。

在交叉合併的狀況下，存在多個合併基礎的狀況下，解決策略的工做方式以下：選擇一種可能的合併基礎，並但願得到最佳合併。 實際上，這並不像聽起來那樣糟糕。 常常發現，用戶一直在處理代碼的不一樣部分。 在這種狀況下，Git會檢測到它正在合併一些已經存在的更改，並跳太重複的更改，從而避免了衝突。 或者，若是這些微小的更改確實引發衝突，則至少衝突應該易於開發人員處理。

我已經使用「解析」成功合併了樹，但默認遞歸策略失敗了。 我已經fatal: git write-tree failed to write a tree錯誤，而且因爲這篇博客文章 （ mirror ），我嘗試了「 -s resolve」，該方法有效。 我仍然不肯定爲何……可是我認爲這是由於我在兩棵樹上都有重複的更改，並解決了「跳過」它們的問題。

---

#2樓

我對解決方法不熟悉，可是我使用了其餘方法：

遞歸的

遞歸是非快進合併的默認設置。 咱們都熟悉那個。

章魚

當我有幾棵須要合併的樹時，我使用了章魚。 您能夠在較大的項目中看到這一點，在該項目中，許多分支機構都具備獨立開發能力，而且全部這些都準備好聚集在一塊兒​​。

章魚分支能夠一次提交地合併多個頭，只要它能夠乾淨地進行便可。

爲了舉例說明，假設您有一個具備母版的項目，而後合併了三個分支（分別稱爲a，b和c）。

一系列遞歸合併看起來像這樣（請注意，第一次合併是快速進行的，由於我沒有強制遞歸）：

可是，單個章魚合併將以下所示：

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...

咱們的

咱們的==我想另當別論，但拋棄了頭腦所帶來的全部變化。

這樣能夠保留分支的歷史記錄，而不會影響分支。

（閱讀：甚至沒有看過這些分支之間的變化。這些分支只是合併而對文件不作任何操做。若是要合併到另外一個分支中，而且每次出現「咱們的文件版本或它們的文件版本版本」，您可使用git merge -X ours ）

子樹

要在另外一個項目中合併到當前項目的子目錄中時，子樹頗有用。 當您擁有不想做爲子模塊包含的庫時，此選項頗有用。

---

#3樓

實際上，若是您要放棄分支帶來的更改，可是將分支保留在歷史記錄中，則只有兩種策略是咱們的策略；若是要將獨立項目合併到超級項目的子目錄中，則能夠選擇子樹 （例如「 git」存儲庫）。

合併兩個以上的分支時，會自動使用章魚合併。 在這裏解決問題主要是因爲歷史緣由，以及當您被遞歸合併策略的極端狀況所打擊時。