?
本文檔使用 php中文網(wǎng)手冊 發(fā)布
名稱
git-rerere - 重復(fù)使用沖突合并的記錄分辨率
概要
git rerere [clear|forget <pathspec>|diff|remaining|status|gc]
描述
在采用相對較長時間的主題分支的工作流中，開發(fā)人員有時需要一遍又一遍地解決相同的沖突，直到主題分支完成（合并到“release”分支，或發(fā)送并接受上游）。
此命令通過在初始手動合并時記錄沖突的自動合并結(jié)果和相應(yīng)的手動分析結(jié)果，并將先前記錄的手動分辨率應(yīng)用于其相應(yīng)的自動合并結(jié)果，來幫助開發(fā)人員處理此過程。
注意 | 您需要設(shè)置配置變量rerere.enabled才能啟用此命令。 |
|---|
命令
通常，git rerere運行時沒有參數(shù)或用戶干預(yù)。但是，它有幾個允許它與其工作狀態(tài)交互的命令。
clear
如果要中止合并分辨率，請重置rerere使用的元數(shù)據(jù)。調(diào)用git am [--skip|--abort]或git rebase [--skip|--abort]將自動調(diào)用此命令。
forget <pathspec>
在<pathspec>中重置針對當前沖突記錄的沖突解決方案。
diff
顯示分辨率當前狀態(tài)的差異。跟蹤用戶解決沖突時更改的內(nèi)容很有用。其他參數(shù)直接傳遞給diff安裝在PATH中的系統(tǒng)命令。
status
具有合并分辨率將會記錄的沖突的打印路徑。
remaining
打印具有尚未由rerere自動解決的沖突的路徑。這包括其分辨率無法通過rerere進行跟蹤的路徑，例如沖突的子模塊。
gc
Prune記錄很久以前發(fā)生的沖突合并。默認情況下，將修剪超過15天的未解決的沖突并修復(fù)60天以上的已解決沖突。這些默認值分別通過gc.rerereUnresolved和gc.rerereResolved配置變量進行控制。
討論
當您的主題分支修改主分支（或上游）在主題分支從其分支后觸及的重疊區(qū)域時，即使在主題分支已準備好向上游推送之前，也可能需要使用最新的主分支進行測試：
o---*---o topic / o---o---o---*---o---o master
對于這樣的測試，您需要以某種方式合并主題和主題。一種方法是將主人拉入主題分支：
$ git checkout topic $ git merge master o---*---o---+ topic / / o---o---o---*---o---o master
標記的提交*觸摸同一文件中的同一區(qū)域; 您需要在創(chuàng)建標記為的提交時解決沖突+。然后，您可以測試結(jié)果，以確保您的工作進行中仍然適用于最新的master。
在這次測試合并之后，有兩種方法可以繼續(xù)您關(guān)于該主題的工作。最簡單的方法是在測試合并提交的基礎(chǔ)上構(gòu)建+，當主題分支中的工作終于準備就緒后，將主題分支拉入主內(nèi)容中，和/或請求上游從您那里撤出。然而到那時，主測試或上游測試合并后可能已經(jīng)進階+，在這種情況下，最終提交圖如下所示：
$ git checkout topic $ git merge master $ ... work on both topic and master branches $ git checkout master $ git merge topic o---*---o---+---o---o topic / / \ o---o---o---*---o---o---o---o---+ master
然而，當你的主題分支是長期存在的時候，你的主題分支最終會有很多這樣的“Merge from master”提交，這會不必要地混淆發(fā)展歷史。Linux內(nèi)核郵件列表的讀者可能還記得，當一個子系統(tǒng)維護者要求從一個充滿“useless merges”的分支中拉出時，Linus抱怨這種頻繁的測試合并。
作為替代方案，為了保持主題分支不受測試合并的干擾，您可以放棄測試合并，并在測試合并之前繼續(xù)構(gòu)建在提示之上：
$ git checkout topic $ git merge master $ git reset --hard HEAD^ ;# rewind the test merge $ ... work on both topic and master branches $ git checkout master $ git merge topic o---*---o-------o---o topic / \ o---o---o---*---o---o---o---o---+ master
當您的主題分支最終準備就緒并合并到主分支時，這將只剩下一個合并提交。此合并將要求您解決標記為的提交引入的沖突*。但是，這種沖突通常與您在創(chuàng)建測試合并時所解決的沖突相同。git rerere使用您早先解決的問題中的信息幫助您解決最終沖突的合并問題。
運行git rerere一個沖突automerge后，立即命令記錄沖突工作樹中的文件，與通常的沖突標志<<<<<<<，=======以及>>>>>>>在其中。稍后，在解決沖突之后，git rerere再次運行將記錄這些文件的已解決狀態(tài)。假設(shè)您在創(chuàng)建主控測試合并到主題分支時執(zhí)行了此操作。
下一次，在看到相同的沖突automerge之后，運行git rerere將執(zhí)行早先沖突的automerge，早期的手動分辨率和當前沖突的automerge之間的三方合并。如果這個三路合并干凈地解決，結(jié)果寫出到您的工作樹文件，因此您不必手動解決它。請注意，git rerere單獨保留索引文件，因此您仍然需要使用git diff（或git diff -c）進行最終的完整性檢查，并且git add當您滿意時。
作為一種便利措施，git merge自動調(diào)用git rerere退出時失敗的自動合并，git rerere并在新的沖突時記錄手的解決方案，或者在不是時重新使用先前的手解決方案。在提交合并結(jié)果時git commit也會調(diào)用git rerere。這意味著你不需要做任何特別的事情（除了啟用rerere.enabled配置變量）。
在我們的示例中，當您進行測試合并時，手動解析會被記錄下來，并且只要記錄的分辨率仍然適用，稍后使用更新的主控和主題分支進行實際合并時，它將被重用。
信息git rerere記錄也在運行時使用git rebase。在主題分支上淘汰測試合并并繼續(xù)開發(fā)之后：
o---*---o-------o---o topic / o---o---o---*---o---o---o---o master $ git rebase master topic o---*---o-------o---o topic / o---o---o---*---o---o---o---o master
您可以運行git rebase master topic，在您的主題準備好向上游發(fā)送之前讓自己保持最新狀態(tài)。這會導(dǎo)致回退到三路合并，并且與您之前解決的測試合并相同。git rerere將通過運行git rebase來幫助你解決這個沖突。