5.3 分散式 Git - 維護專案

如果你收到的補丁是使用 git diff 或 Unix diff 命令的某種變體（不推薦這樣做；詳見下一節）生成的，你可以使用 git apply 命令來應用它。假設你將補丁儲存在 /tmp/patch-ruby-client.patch，你可以這樣應用補丁：

這會修改你的工作目錄中的檔案。它幾乎與執行 patch -p1 命令來應用補丁相同，儘管它更謹慎，並且接受的模糊匹配比 patch 少。如果檔案新增、刪除和重新命名是以 git diff 格式描述的，它也能處理，而 patch 則不能。最後，git apply 是一種“全部應用或全部中止”的模型，要麼全部應用，要麼全部不應用，而 patch 可以部分應用補丁檔案，使你的工作目錄處於奇怪的狀態。git apply 總體上比 patch 更保守。它不會為你建立提交——執行它之後，你必須手動暫存並提交所引入的更改。

你還可以使用 git apply 來檢視補丁是否能幹淨地應用，然後再實際嘗試應用它——你可以使用 git apply --check 選項執行補丁：

如果沒有輸出，那麼補丁應該能夠乾淨地應用。如果檢查失敗，此命令還會以非零狀態退出，因此如果你願意，可以在指令碼中使用它。

如果貢獻者是 Git 使用者，並且很好地使用了 format-patch 命令來生成補丁，那麼你的工作就會更容易，因為該補丁包含了作者資訊和提交資訊。如果可以，鼓勵你的貢獻者使用 format-patch 而不是 diff 來為你生成補丁。你應該只對舊式補丁等使用 git apply。

要應用由 format-patch 生成的補丁，你使用 git am（該命令名為 am 是因為它用於“從郵箱中應用一系列補丁”）。從技術上講，git am 被設計用於讀取 mbox 檔案，這是一種簡單的純文字格式，用於將一個或多個電子郵件訊息儲存在一個文字檔案中。它看起來像這樣：

這是你在上一節中看到的 git format-patch 命令輸出的開頭；它也代表了一種有效的 mbox 電子郵件格式。如果有人使用 git send-email 正確地透過電子郵件將補丁傳送給你，並且你將補丁下載為 mbox 格式，那麼你可以將 git am 指向該 mbox 檔案，它將開始應用它看到的所有補丁。如果你執行的郵件客戶端可以將多封郵件儲存為 mbox 格式，你可以將整個補丁系列儲存到一個檔案中，然後使用 git am 一次應用一個。

然而，如果有人透過 git format-patch 生成的補丁檔案上傳到票務系統或類似的地方，你可以將該檔案儲存在本地，然後將磁碟上儲存的檔案傳遞給 git am 來應用它：

你可以看到它已乾淨地應用並自動為你建立了新的提交。作者資訊取自電子郵件的 From 和 Date 標頭，提交的訊息取自電子郵件的 Subject 和正文（補丁之前的部分）。例如，如果此補丁是根據上面 mbox 示例應用的，生成的提交將如下所示：

Commit 資訊表示應用此補丁的人員和應用時間。Author 資訊是最初建立此補丁的人員和最初建立時間。

但補丁可能無法乾淨地應用。也許你的主分支與補丁所基於的分支偏離太遠，或者該補丁依賴於你尚未應用的另一個補丁。在這種情況下，git am 程序將失敗並詢問你想要做什麼：

此命令會在任何有問題的檔案中放置衝突標記，非常類似於衝突的合併或 rebase 操作。你解決這個問題的方式大致相同——編輯檔案以解決衝突，暫存新檔案，然後執行 git am --resolved 以繼續下一個補丁：

如果你想讓 Git 更智慧地嘗試解決衝突，可以向其傳遞 -3 選項，這會使 Git 嘗試進行三方合併。此選項預設不啟用，因為如果補丁宣告其所基於的提交不在你的倉庫中，它將不起作用。如果你確實擁有該提交——如果補丁是基於一個公共提交——那麼 -3 選項在應用衝突補丁時通常會更智慧：

在這種情況下，如果沒有 -3 選項，該補丁將被視為衝突。由於使用了 -3 選項，補丁已乾淨地應用。

如果你正在從 mbox 應用多個補丁，你也可以在互動模式下執行 am 命令，它會在找到每個補丁時停止並詢問你是否要應用它：

如果你儲存了多個補丁，這會很方便，因為如果你不記得補丁是什麼，可以先檢視它，或者如果你已經應用過該補丁，則不應用它。

當你的主題的所有補丁都已應用並提交到你的分支中時，你可以選擇是否以及如何將它們整合到長期執行的分支中。

一種基本的工作流是簡單地將所有工作直接合併到你的 master 分支中。在這種情況下，你有一個 master 分支，其中包含基本穩定的程式碼。當你的主題分支中有你認為已完成的工作，或者別人貢獻且你已驗證過的工作時，你將其合併到你的 master 分支，刪除剛剛合併的主題分支，然後重複此過程。

例如，如果我們的倉庫中有兩個名為 ruby_client 和 php_client 的分支，其工作情況如下所示：包含多個主題分支的歷史，如果我們先合併 ruby_client 再合併 php_client，你的歷史記錄將如下所示：主題分支合併後。

這可能是最簡單的工作流，但如果你正在處理更大或更穩定的專案，並且希望對引入的內容非常謹慎，那麼這可能會有問題。

如果你有一個更重要的專案，你可能希望使用兩階段合併週期。在這種情況下，你有兩個長期執行的分支，master 和 develop，你在此方案中確定 master 僅在釋出非常穩定的版本時更新，並且所有新程式碼都整合到 develop 分支中。你定期將這兩個分支推送到公共倉庫。每次有新的主題分支要合併時（主題分支合併前），你將其合併到 develop 中（主題分支合併後）；然後，當你標記釋出時，你將 master 快進到當前穩定的 develop 分支所在的位置（專案釋出後）。

這樣，當人們克隆你的專案倉庫時，他們既可以檢出 master 來構建最新的穩定版本並輕鬆保持更新，也可以檢出 develop，這是更前沿的內容。你還可以擴充套件這個概念，設定一個 integrate 分支，所有工作都在其中合併。然後，當該分支上的程式碼庫穩定並透過測試時，你將其合併到 develop 分支；當 develop 分支已經穩定一段時間後，你再快進你的 master 分支。

Git 專案有四個長期執行的分支：master、next 和 seen（以前是 'pu'——提議的更新），用於新工作，以及 maint 用於維護回溯。當貢獻者引入新工作時，它們以類似於我們所描述的方式收集到維護者的倉庫中的主題分支中（參見管理一系列複雜的並行貢獻主題分支）。此時，對主題進行評估，以確定它們是否安全並可供使用，或者是否需要更多工作。如果它們安全，則將其合併到 next 中，並將該分支推送上去，以便所有人都可以嘗試整合在一起的主題。

如果主題仍需要工作，則將其合併到 seen 中。當確定它們完全穩定時，這些主題會重新合併到 master 中。next 和 seen 分支隨後從 master 重建。這意味著 master 幾乎總是向前推進，next 偶爾會 rebase，而 seen 則更頻繁地 rebase：

當一個主題分支最終合併到 master 中時，它將從倉庫中移除。Git 專案還有一個 maint 分支，它是從上次釋出中分叉出來的，用於在需要維護髮布時提供回溯補丁。因此，當你克隆 Git 倉庫時，你有四個分支可以檢出，以便在不同的開發階段評估專案，這取決於你想要多麼前沿或你想要如何貢獻；維護者有一個結構化的工作流來幫助他們審查新的貢獻。Git 專案的工作流是專門化的。要清楚地理解這一點，你可以查閱 Git 維護者指南。

其他維護者傾向於在其 master 分支之上 rebase 或 cherry-pick 貢獻的工作，而不是合併它，以保持大部分線性的歷史記錄。當你的主題分支中有工作並確定要整合它時，你切換到該分支並執行 rebase 命令，以在當前 master（或 develop 等）分支之上重建更改。如果這順利進行，你可以快進你的 master 分支，最終你將獲得一個線性的專案歷史記錄。

將引入的工作從一個分支移動到另一個分支的另一種方法是 cherry-pick 它。Git 中的 cherry-pick 就像單個提交的 rebase。它獲取提交中引入的補丁，並嘗試將其重新應用到你當前所在的分支上。如果你在主題分支上有多個提交併且你只想整合其中一個，或者如果你的主題分支上只有一個提交併且你更喜歡 cherry-pick 它而不是執行 rebase，這會很有用。例如，假設你有一個專案，它看起來像這樣：

如果你想將提交 e43a6 拉取到你的 master 分支中，你可以執行：

這會拉取在 e43a6 中引入的相同更改，但你會得到一個新的提交 SHA-1 值，因為應用日期不同。現在你的歷史記錄看起來像這樣：

現在你可以刪除你的主題分支，並放棄你不想拉取的提交。

如果你經常進行合併和 rebase 操作，或者你正在維護一個長期存在的主題分支，Git 有一個名為“rerere”的功能可以提供幫助。

Rerere 代表“重用已記錄的解決方案”（“reuse recorded resolution”）——這是一種簡化手動解決衝突的方法。當 rerere 啟用時，Git 會保留一組成功合併的前後影像，如果它注意到某個衝突與你已經修復過的衝突完全相同，它就會直接使用上次的修復方案，而無需你再次干預。

這個功能包括兩個部分：一個配置設定和一個命令。配置設定是 rerere.enabled，它非常方便，可以新增到你的全域性配置中：

現在，無論何時你進行合併並解決衝突，該解決方案都將記錄在快取中，以備將來使用。

如果需要，你可以使用 git rerere 命令與 rerere 快取進行互動。當它單獨呼叫時，Git 會檢查其解決方案資料庫，並嘗試與任何當前合併衝突匹配並解決它們（儘管如果 rerere.enabled 設定為 true，這會自動完成）。還有子命令可以檢視將記錄什麼，從快取中清除特定解決方案，以及清除整個快取。我們將在Rerere中更詳細地介紹 rerere。