我發現合併工具很少能幫助我理解衝突或解決方案。我通常更成功地在文字編輯器中檢視衝突標記並使用git log作為補充。
提示一我發現的最好的事情是使用「diff3」合併衝突樣式：
git config merge.conflictstyle diff3
這會產生如下衝突標記：<<<<<<
|||||||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
這顯示了在共同祖先和您要合併的兩個頭之間觸及該檔案的所有提交。(因此它不包括在合併之前已存在於兩個分支中的提交。)這有助於您忽略明顯不是當前衝突因素的差異。
提示三使用自動化工具驗證您的更改。
提示四未雨綢繆; 與同事溝通。
提前規劃並了解其他人正在進行的工作可以幫助防止合併衝突和/或幫助他們更早地解決這些問題 - 而細節仍然是新鮮的。
例如，如果您知道您和另乙個人都在進行不同的重構，這兩個重構都會影響同一組檔案，那麼您應該提前相互交談並更好地了解每個人的變化型別。製造。如果您按順序而不是並行地執行計畫的更改，則可能會節省大量時間和精力。
對於跨越大量**的主要重構，您應該強烈考慮連續工作：當乙個人執行完整的重構時，每個人都停止在**的該區域工作。
如果你不能連續工作(可能由於時間壓力)，那麼溝通預期的合併衝突至少可以幫助你更快地解決問題，同時細節仍然是新鮮的。例如，如果同事在一周的時間內進行了一系列破壞性的提交，您可以選擇在該周期間每天一次或兩次合併/重組該同事分支。這樣，如果你確實發現了合併/ rebase衝突，你可以比等待幾周將所有內容合併成乙個大塊的更快地解決它們。
提示五如果您不確定合併，請不要強行合併。
合併可能會讓人感到壓力，特別是當存在大量衝突檔案且衝突標記覆蓋數百行時。通常，在估算軟體專案時，我們沒有足夠的時間來處理開銷專案，例如處理粗糙的合併，因此花費幾個小時來解決每個衝突感覺真的很麻煩。
從長遠來看，提前規劃並了解其他人正在進行的工作是**合併衝突並準備好在更短的時間內正確解決衝突的最佳工具。
git如何解衝突 使用git時，如何解決衝突
下面，通過乙個例項來演示，模擬開發中的一種衝突的情況 準備工作 第一步在本地檔案中建立乙個git倉庫 可見，此時，head指標指向master分支。然後新建檔案,readme.txt 新增內容 the content belongs to master 最後add commit 第二步建立 切換到d...
git 找到衝突 Git如何解決衝突
當您在乙個團隊中工作的時候，當有人將更改推送到您當前正在處理的檔案時，您可能會遇到這種情況。如果這些更改不重疊 即對不同的 行進行了更改 則會自動合併衝突的檔案。但是，如果同一行受到影響，則git不能隨意選擇另一方，並要求您解決衝突。在git中，當您嘗試執行下列操作之一時，衝突可能會出現 pull ...
Git如何解決本地衝突（純淨版）
第一步 拉取遠端最新 git fetch a第二步 切換到源分支 如果本地有源分支 git checkout branch new如果本地沒有源分支 git checkout b branch new origin branch new第三步 合併 此處，不要使用fast forward容易，覆蓋合...