在人混帳合併文檔，git merge -s recursive -X ours：git merge -s遞歸-X我們vs git merge -s我們的？
這不應該與我們的混淆合併戰略，它不 連看都不看對方是什麼樹包含在所有。它丟棄了 其他樹所做的一切，聲明我們的歷史包含發生在其中的所有 。
我已經測試了這兩個，但是找不到差別。
有沒有例子說明這兩者有何區別？
我的Git版本是git version 1.8.3.4
正如手冊頁所述，-s ours完全忽略了其他分支的內容。這應該足夠明顯了：不管其他分支中的內容是什麼，附加到合併提交的樹與合併前HEAD提交中的樹相同。
什麼-X ours確實比較微妙：它僅在存在衝突時使用「我們」版本的更改。
這裏有一個比較簡單的例子。
假設您在分支br1上，並且您要求合併分支br2。我們會讓這些非常簡單的，要提交有一個單獨的分支br1提交KB（爲兩個分支的合併基礎原點），和一個單獨的分支br2提交L：
... - B - K <-- HEAD=br1
\
L <-- br2
此外，從差B到K僅由一個項目：
f1：更換第一線dog與cat同時，從B到L的區別包括：
f1：與poodlef2替換第一行dog：替換最後一行elephant與rhinoceros當您將這些合併爲沒有策略或選項時，會有b e文件f1（對同一行的不同更改）中存在衝突，但不在f2中（合併提交將在提交L中進行更改，以便文件f2將發生更改）。
如果你使用：
git merge -s ours br2
合併命令將使用 「我們」 版本的文件f1的（dog變得cat），，也是我們的文件f2的版本（elephant不變）。
如果你使用：
git merge -s recursive -X ours
合併命令會發現文件f1衝突，將解決它有利於我們的版本，這是因爲之前相同，但對文件f2沒有衝突，所以git會使用他們的版本f2（elephant變成rhinoceros）。
（這個簡單的例子並沒有顯示是否有f1或f2在不同區域的兩個不同的變化會發生什麼。如果f1足夠長，有一個在提交修改L進一步跌多「的文件的第一行」 ，合併可以接受該更改，因爲它不會與dog至cat更改發生衝突。）
我不知道有什麼具體的例子，但不同的是這樣的：
git merge -s recursive -X ours
這確實一個「正常」的合併（該recursive策略是默認一個）和，當發現衝突時，它會嘗試通過自動使用合併到（「我們的」）分支中的代碼片段來解決這些衝突，而不是留下衝突標記。
git merge -s ours
正如你所引用的文件說，這需要我們的代碼版本，在它的全部，並使其成爲合併的結果 - 另一個分支甚至沒有看，沒有檢測到衝突，等等。它只是簡單地說「創建一個新的提交，看起來像合併了另一個分支，但將結果內容與當前分支完全一樣」。