5.3 分散式 Git - 維護專案

如果你從某人那裡收到使用 git diff 或 Unix diff 命令（不建議使用；請參閱下一節）產生的 patch，你可以使用 git apply 命令套用它。假設你將 patch 儲存在 /tmp/patch-ruby-client.patch，你可以這樣套用 patch：

這會修改你工作目錄中的檔案。它幾乎等同於執行 patch -p1 命令來套用 patch，儘管它更加謹慎，並且比 patch 接受較少的模糊匹配。如果檔案新增、刪除和重新命名是以 git diff 格式描述的，它也會處理這些情況，而 patch 不會這樣做。最後，git apply 是一個「全部套用或全部中止」的模型，其中要麼全部套用，要麼全部不套用，而 patch 可以部分套用 patch 檔案，使你的工作目錄處於奇怪的狀態。總體而言，git apply 比 patch 更為保守。它不會為你建立 commit — 執行後，你必須手動暫存並提交引入的變更。

你也可以使用 git apply 來查看 patch 在實際嘗試套用之前是否能順利套用 — 你可以使用 patch 執行 git apply --check

如果沒有輸出，則表示該 patch 應能順利套用。如果檢查失敗，此命令也會以非零狀態退出，因此你可以在腳本中使用它。

如果貢獻者是 Git 使用者，並且很樂意使用 format-patch 命令來產生他們的 patch，那麼你的工作會更輕鬆，因為 patch 包含作者資訊和給你的 commit 訊息。如果可以，請鼓勵你的貢獻者使用 format-patch 而不是 diff 來為你產生 patch。你應該只需要將 git apply 用於舊有的 patch 和類似的東西。

要套用由 format-patch 產生的 patch，你可以使用 git am （該命令名為 am，因為它用於「從郵件匣套用一系列 patch」）。從技術上講，git am 的構建是為了讀取 mbox 檔案，這是一種簡單的純文字格式，用於在一個文字檔案中儲存一個或多個電子郵件訊息。它看起來像這樣：

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

但是，如果有人將透過 git format-patch 產生的 patch 檔案上傳到票務系統或類似系統，你可以將該檔案儲存在本地，然後將儲存在磁碟上的該檔案傳遞給 git am 以套用它

你可以看到它順利套用了，並且自動為你建立了新的 commit。作者資訊取自電子郵件的 From 和 Date 標頭，並且 commit 的訊息取自電子郵件的 Subject 和主體（在 patch 之前）。例如，如果此 patch 是從上面的 mbox 範例套用的，則產生的 commit 將如下所示：

Commit 資訊表示套用 patch 的人和套用時間。Author 資訊是最初建立 patch 的個人和最初建立時間。

但是，patch 可能無法順利套用。也許你的主分支已經與建立 patch 的分支偏離太遠，或者 patch 依賴於你尚未套用的另一個 patch。在這種情況下，git am 流程將會失敗，並詢問你想做什麼

此命令會在它有問題的任何檔案中放置衝突標記，很像衝突合併或變基操作。你解決此問題的方式非常相似 — 編輯檔案以解決衝突，暫存新檔案，然後執行 git am --resolved 以繼續下一個 patch

如果你想讓 Git 更聰明地嘗試解決衝突，你可以將 -3 選項傳遞給它，這會使 Git 嘗試三向合併。預設情況下不啟用此選項，因為如果 patch 聲稱基於的 commit 不在你的儲存庫中，則該選項不起作用。如果你確實有該 commit — 如果 patch 是基於你擁有存取權的公開 commit — 那麼 -3 選項通常在套用衝突 patch 時會更加聰明

在這種情況下，如果沒有 -3 選項，patch 會被視為衝突。由於使用了 -3 選項，因此 patch 已順利套用。

如果要從 mbox 套用多個 patch，你也可以在互動模式下執行 am 命令，該命令會在找到的每個 patch 處停止，並詢問你是否要套用它

如果你儲存了多個 patch，這很方便，因為你可以先檢視 patch（如果你不記得它是什麼），或者如果你已經套用過 patch，則不套用它。

當你的主題的所有 patch 都已套用並提交到你的分支時，你可以選擇是否以及如何將它們整合到更長的分支中。

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

舉例來說，如果我們有一個儲存庫，其中包含在兩個名為 ruby_client 和 php_client 的分支上的工作，其外觀如具有多個主題分支的歷史記錄所示，並且我們依序合併 ruby_client 和 php_client，那麼你的歷史記錄最終會看起來像主題分支合併後所示。

這可能是最簡單的工作流程，但如果你處理的是較大型或更穩定的專案，而你又希望對引入的內容非常謹慎時，這可能會出現問題。

如果你的專案更重要，你可能會想使用兩階段的合併週期。在這種情況下，你有兩個長時間運行的分支，master 和 develop，你決定只有在建立非常穩定的版本時才更新 master，而所有新程式碼都會整合到 develop 分支中。你會定期將這兩個分支推送到公開儲存庫。每次你有新的主題分支要合併時（在主題分支合併之前），你會將其合併到 develop 中（在主題分支合併之後）；然後，當你標記版本時，你會將 master 快轉到現在穩定的 develop 分支所在的位置（在專案發佈之後）。

這樣一來，當人們複製你的專案儲存庫時，他們可以簽出 master 來建立最新的穩定版本，並輕鬆保持更新，或者他們可以簽出 develop，這是更前沿的內容。你也可以透過擁有一個 integrate 分支來擴展這個概念，所有工作都會合併到其中。然後，當該分支上的程式碼庫穩定並通過測試時，你會將其合併到 develop 分支中；而當它證明自身穩定一段時間後，你會快轉你的 master 分支。

Git 專案有四個長時間運行的分支：master、next 和 seen（以前稱為 'pu' - 提議更新）用於新工作，而 maint 用於維護性的反向移植。當貢獻者引入新工作時，它們會以類似於我們描述的方式收集到維護者的儲存庫中的主題分支中（請參閱管理複雜的平行貢獻主題分支系列）。此時，會評估這些主題，以確定它們是否安全且可以接受，或者是否需要更多工作。如果它們是安全的，則會將它們合併到 next 中，並將該分支推送上去，以便所有人都可以嘗試整合在一起的主題。

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

當一個主題分支最終合併到 master 中時，它會從儲存庫中刪除。Git 專案還有一個 maint 分支，它是從最後一個版本分叉出來的，以便在需要維護版本時提供反向移植的修補程式。因此，當你複製 Git 儲存庫時，你可以簽出四個分支，以評估專案在不同開發階段的狀況，具體取決於你想要多前沿，或者你想要如何貢獻；而維護者則有一個結構化的工作流程，以協助他們審核新的貢獻。Git 專案的工作流程是專門化的。為了清楚理解這一點，你可以查看Git 維護者指南。

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

將引入的工作從一個分支移動到另一個分支的另一種方法是 cherry-pick。Git 中的 cherry-pick 就像是針對單一 commit 的 rebase。它會取得在 commit 中引入的修補程式，並嘗試將其重新應用到你目前所在的分支上。如果你在主題分支上有許多 commit，並且只想整合其中一個 commit，或者你只有一個主題分支上的 commit，並且你傾向於 cherry-pick 而不是執行 rebase 時，這會很有用。例如，假設你有的專案看起來像這樣

如果你想將 commit e43a6 拉到你的 master 分支中，你可以執行

這會拉入在 e43a6 中引入的相同變更，但你會獲得一個新的 commit SHA-1 值，因為套用的日期不同。現在你的歷史記錄看起來像這樣

現在你可以移除你的主題分支並捨棄你不想拉入的 commit。

如果你正在執行大量合併和 rebase，或者你正在維護一個長期存在的主題分支，Git 有一個名為「rerere」的功能可以提供協助。

Rerere 代表「reuse recorded resolution（重複使用記錄的解決方案）」— 這是一種捷徑來處理手動衝突解決的方法。啟用 rerere 後，Git 會保留成功合併的 pre- 和 post- 映像集，如果它注意到有一個衝突看起來和你已經修復的衝突完全一樣，它只會使用上次的修復，而不會打擾你。

此功能分為兩個部分：組態設定和命令。組態設定是 rerere.enabled，將其放入全域設定中會很方便

現在，每當你執行會解決衝突的合併時，解決方案就會記錄在快取中，以備將來使用。

如果需要，你可以使用 git rerere 命令與 rerere 快取互動。當單獨叫用時，Git 會檢查其解決方案資料庫，並嘗試找出與任何目前合併衝突相符的項目並解決它們（儘管如果 rerere.enabled 設定為 true，則會自動執行此操作）。還有一些子命令可以用於查看將要記錄的內容、從快取中刪除特定解決方案，以及清除整個快取。我們將在Rerere中更詳細地介紹 rerere。