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 格式，那麼你就可以將 mbox 檔案指向 git am，它將開始應用它看到的所有補丁。如果你使用的郵件客戶端可以將多個電子郵件儲存為 mbox 格式，你可以將整個補丁系列儲存到一個檔案中，然後使用 git am 一次應用一個。

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

你可以看到它乾淨地應用了，並且自動為你建立了新的提交。作者資訊是從郵件的 From 和 Date 標頭中獲取的，提交資訊是從郵件的主題和正文（在補丁之前）中獲取的。例如，如果這個補丁是從上面的 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 分支；當它穩定一段時間後，你將 master 分支快進。

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

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

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

其他維護者更喜歡將貢獻的工作 rebase 或 cherry-pick 到他們的 master 分支之上，而不是合併進去，以保持一個大致線性的歷史。當你有一個主題分支中的工作並已決定將其整合，你切換到該分支並執行 rebase 命令，以在你的當前 master（或 develop 等）分支之上重建更改。如果工作進展順利，你可以快進你的 master 分支，你最終會得到一個線性的專案歷史。

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

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

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

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

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

Rerere 的意思是“重用已記錄的解決”——這是一種簡化手動衝突解決的方法。當 rerere 啟用時，Git 會儲存成功合併的前後影像集，如果它注意到一個衝突與你已經修復過的衝突完全相同，它就會直接使用上次的修復，而不會打擾你。

此功能包含兩個部分：一個配置設定和一個命令。配置設定是 rerere.enabled，將其新增到全域性配置中非常方便：

現在，無論何時你進行一個解決了衝突的合併，解決方法都會被記錄在快取中，以備將來需要。

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