嘗試： git mergetool

它會打開一個GUI，引導您完成每個沖突，然后您可以選擇合并方式。有時它需要稍后進行一些手工編輯，但通常它本身就足夠了。這肯定比手工做整件事要好得多。

根據@JoshGlover評論：

除非您安裝GUI，否則該命令不一定會打開GUI。git mergetool為我跑步導致vimdiff被使用。您可以安裝以下工具之一，而不是使用它：meld，opendiff，kdiff3，tkdiff，xxdiff，tortoisemerge，gvimdiff，diffuse，ecmerge，p4merge，araxis，vimdiff，emerge。

以下是vimdiff用于解決合并沖突的示例過程?；?a >此鏈接

步驟1：在終端中運行以下命令

git config merge.tool vimdiffgit config merge.conflictstyle diff3git config mergetool.prompt false

這會將vimdiff設置為默認合并工具。

步驟2：在終端中運行以下命令

git mergetool

第3步：您將看到以下格式的vimdiff顯示

 +----------------------+

  |       |      |       |

  |LOCAL  |BASE  |REMOTE |

  |       |      |       |

  +----------------------+

  |      MERGED          |

  |                      |

  +----------------------+

這4個觀點是

LOCAL - 這是當前分支的文件

BASE - 共同的祖先，文件在兩個變化之前看起來如何

REMOTE - 您正在合并到您的分支機構的文件

合并 - 合并結果，這是在回購中保存的內容

您可以使用在這些視圖之間導航ctrl+w。您可以直接使用MERGED視圖，ctrl+w然后使用j。

有關Vimdiff可以導航更多信息在這里和這里

第4步。您可以通過以下方式編輯MERGED視圖

如果您想從REMOTE獲得更改

:diffg RE

如果您想從BASE獲得更改

:diffg BA

如果您想從LOCAL獲得更改

:diffg LO

第5步。保存，退出，提交和清理

:wqa 保存并退出vi

git commit -m "message"

git clean 刪除diff工具創建的額外文件（例如* .orig）。

這是一個可能的用例，從頂部：

你要做一些改變，但是哎呀，你不是最新的：

git fetch origin

git pull origin master

From ssh://[email protected]:22/projectname

 * branch            master     -> FETCH_HEAD

Updating a030c3a..ee25213

error: Entry 'filename.c' not uptodate. Cannot merge.

所以你得到最新的并再試一次，但是有沖突：

git add filename.c

git commit -m "made some wild and crazy changes"

git pull origin master

From ssh://[email protected]:22/projectname

 * branch            master     -> FETCH_HEAD

Auto-merging filename.c

CONFLICT (content): Merge conflict in filename.c

Automatic merge failed; fix conflicts and then commit the result.

所以你決定看一下這些變化：

git mergetool

哦，我，我的，上游改變了一些事情，但只是為了使用我的改變......不......他們的改變......

git checkout --ours filename.c

git checkout --theirs filename.c

git add filename.c

git commit -m "using theirs"

然后我們嘗試最后一次

git pull origin master

From ssh://[email protected]:22/projectname

 * branch            master     -> FETCH_HEAD

Already up-to-date.

當當！

我發現合并工具很少能幫助我理解沖突或解決方案。我通常更成功地在文本編輯器中查看沖突標記并使用git log作為補充。

以下是一些提示：

提示一

我發現的最好的事情是使用“diff3”合并沖突樣式：

git config merge.conflictstyle diff3

這會產生如下沖突標記：

<<<<<<<Changes made on the branch that is being merged into. In most cases,this is the branch that I have currently checked out (i.e. HEAD).
|||||||The common ancestor version.=======Changes made on the branch that is being merged in. This is often a feature/topic branch.>>>>>>>

中間部分是共同祖先的樣子。這很有用，因為您可以將其與頂部和底部版本進行比較，以更好地了解每個分支上的更改內容，從而更好地了解每個更改的目的。

如果沖突只有幾行，這通常會使沖突非常明顯。（知道如何解決沖突是非常不同的;你需要知道其他人正在做什么。如果你感到困惑，最好是把那個人叫到你的房間，這樣他們就能看到你在看什么在。）

如果沖突時間較長，那么我會將這三個部分中的每一部分剪切并粘貼到三個單獨的文件中，例如“我的”，“普通”和“他們的”。

然后我可以運行以下命令來查看導致沖突的兩個差異：

diff common minediff common theirs

這與使用合并工具不同，因為合并工具也將包括所有非沖突的差異。我覺得這會分散注意力。

提示二

有人已經提到了這一點，但了解每個差異背后的意圖通常非常有助于了解沖突的來源以及如何處理沖突。

git log --merge -p <name of file>

這顯示了在共同祖先和您要合并的兩個頭之間觸及該文件的所有提交。（因此它不包括在合并之前已存在于兩個分支中的提交。）這有助于您忽略明顯不是當前沖突因素的差異。

提示三

使用自動化工具驗證您的更改。

如果您有自動化測試，請運行它們。如果你有一個棉絨，那就跑吧。如果它是一個可構建的項目，那么在你提交之前構建它等等。在所有情況下，你需要做一些測試，以確保你的更改沒有破壞任何東西。（哎呀，即使沒有沖突的合并也會破壞工作代碼。）

提示四

未雨綢繆; 與同事溝通。

提前規劃并了解其他人正在進行的工作可以幫助防止合并沖突和/或幫助他們更早地解決這些問題 - 而細節仍然是新鮮的。

例如，如果您知道您和另一個人都在進行不同的重構，這兩個重構都會影響同一組文件，那么您應該提前相互交談并更好地了解每個人的變化類型。制造。如果您按順序而不是并行地執行計劃的更改，則可能會節省大量時間和精力。

對于跨越大量代碼的主要重構，您應該強烈考慮連續工作：當一個人執行完整的重構時，每個人都停止在代碼的該區域工作。

如果你不能連續工作（可能由于時間壓力），那么溝通預期的合并沖突至少可以幫助你更快地解決問題，同時細節仍然是新鮮的。例如，如果同事在一周的時間內進行了一系列破壞性的提交，您可以選擇在該周期間每天一次或兩次合并/重組該同事分支。這樣，如果你確實發現了合并/ rebase沖突，你可以比等待幾周將所有內容合并成一個大塊的更快地解決它們。

提示五

如果您不確定合并，請不要強行合并。

合并可能會讓人感到壓力，特別是當存在大量沖突文件且沖突標記覆蓋數百行時。通常，在估算軟件項目時，我們沒有足夠的時間來處理開銷項目，例如處理粗糙的合并，因此花費幾個小時來解決每個沖突感覺真的很麻煩。

從長遠來看，提前規劃并了解其他人正在進行的工作是預測合并沖突并準備好在更短的時間內正確解決沖突的最佳工具。

1. 確定哪些文件存在沖突（Git應該告訴您）。

2. 打開每個文件并檢查差異; Git劃定了他們。希望很明顯每個塊的哪個版本要保留。您可能需要與提交代碼的開發人員討論它。

3. 一旦解決了文件中的沖突git add the_file。

4. 一旦你解決了所有的沖突，就git rebase --continue可以完成Git在完成時要做的命令。