當某個功能從實驗性變為穩定時，它也會在軟體的對應分支之間「畢業」。git.git 使用以下整合分支：

還有第四個官方分支，其使用方式略有不同：

這四個分支中的每一個通常都是其上方分支的直接後代。

從概念上講，功能進入不穩定的分支（通常是 next 或 seen），一旦被認為足夠穩定，就會「畢業」到 master 以進行下一次發佈。

上述討論的「向下畢業」無法透過實際進行向下合併來完成，因為那樣會將不穩定分支上的所有變更合併到穩定分支中。因此有以下規定：

這能提供一個受控的修復流程。如果你發現你對例如 master 應用了一個同樣需要於 maint 中的修復，你將需要（使用 git-cherry-pick[1]）將其向下挑揀。這種情況偶爾會發生，除非你非常頻繁地這樣做，否則不必擔心。

任何非平凡的功能都需要多個修補程式來實作，並且在其生命週期中可能會獲得額外的錯誤修復或改進。

直接在整合分支上提交所有內容會導致許多問題：糟糕的提交無法撤銷，因此必須逐一還原，這會導致混亂的歷史記錄，並在忘記還原部分變更組時產生進一步的錯誤潛力。並行工作會混淆變更，造成進一步的混亂。

使用「主題分支」可以解決這些問題。名稱本身就解釋了一切，但要注意上面提到的「向上合併」規則：

這樣，許多事情就可以非常自然地完成：

請注意，最後一點與前兩點衝突：已經合併到其他地方的主題不應重定基準（rebased）。參見 git-rebase[1] 中的「從上游重定基準中恢復」一節。

我們應該指出，「習慣性地」（即無故地定期）將整合分支合併到你的主題中——並延伸開來，定期將任何上游合併到任何下游——是不被提倡的：

否則，被合併到的主題會突然包含超過單一（定義明確的）變更。由此產生的許多小合併將極大地混亂歷史記錄。任何稍後調查檔案歷史的人都將不得不弄清楚該合併是否影響了正在開發的主題。上游甚至可能無意中被合併到一個「更穩定」的分支中。依此類推。

如果你遵循了上一段，你現在將擁有許多小的主題分支，並且偶爾會好奇它們是如何互動的。也許合併後的結果甚至無法運作？但另一方面，我們希望避免將它們合併到任何「穩定」的地方，因為這樣的合併無法輕易撤銷。

解決方案當然是進行一個我們可以撤銷的合併：合併到一個拋棄式分支中。

如果你能非常清楚地說明該分支將在測試後立即刪除，你甚至可以發佈此分支，例如讓測試人員有機會與其合作，或讓其他開發人員有機會查看他們正在進行的工作是否相容。git.git 有一個名為 seen 的官方拋棄式整合分支。

假設你正在使用上述討論的合併方法，當你發佈你的專案時，你需要進行一些額外的分支管理工作。

功能發佈是從 master 分支建立的，因為 master 追蹤應納入下一個功能發佈的提交。

master 分支應該是 maint 的超集。如果不滿足此條件，則 maint 包含一些未包含在 master 中的提交。因此，這些提交所代表的修復將不會包含在你的功能發佈中。

要驗證 master 確實是 maint 的超集，請使用 git log：

此指令不應列出任何提交。否則，請檢出 master 並將 maint 合併到其中。

現在你可以繼續進行功能發佈的建立。在 master 的尖端貼上一個標籤，指明發佈版本：

你需要將新標籤推送到公共 Git 伺服器（參見下方的「分散式工作流程」）。這使得追蹤你專案的其他人可以使用該標籤。推送還可以觸發 post-update 鉤子來執行與發佈相關的項目，例如建立發佈 tarball 和預格式化的文件頁面。

同樣地，對於維護版本發佈，maint 正在追蹤要發佈的提交。因此，在上述步驟中，只需標記並推送 maint 而不是 master。

在功能發佈之後，你需要管理你的維護分支。

首先，如果你希望繼續為最近一次之前的發佈版本發佈維護修復，那麼你必須建立另一個分支來追蹤該先前發佈版本的提交。

為此，將當前的維護分支複製到另一個以先前發佈版本號命名的分支（例如 maint-X.Y.(Z-1)，其中 X.Y.Z 是當前版本）。

maint 分支現在應該快進（fast-forwarded）到新發佈的程式碼，以便可以為當前版本追蹤維護修復：

如果合併失敗，因為它不是快進，那麼可能 maint 上的一些修復在功能發佈中遺漏了。如果分支內容已按上一節所述進行驗證，則不會發生這種情況。

在功能發佈之後，整合分支 next 可以選擇性地回退，並使用 next 上倖存的主題從 master 的尖端重建：

這樣做的好處是 next 的歷史記錄將保持乾淨。例如，某些合併到 next 的主題最初看起來很有希望，但後來發現不理想或為時過早。在這種情況下，該主題會從 next 中還原，但歷史記錄中仍然存在它曾經被合併和還原的事實。透過重新建立 next，你為此類主題的另一個化身提供了重新嘗試的乾淨狀態，而功能發佈是歷史記錄中這樣做的合適點。

如果你這樣做，那麼你應該發佈一個公開公告，表明 next 已被回退並重建。

同樣的回退和重建過程可以對 seen 進行。由於 seen 如上所述是一個拋棄式分支，因此不需要公開公告。

合併工作流程透過在上游和下游之間複製分支來運作。上游可以將貢獻合併到官方歷史記錄中；下游基於官方歷史記錄開展工作。

有三種主要工具可用於此：

注意最後一點。除非你確實想合併遠端分支，否則不要使用 git pull。

發佈變更很容易：

你仍然必須透過其他方式通知人們，例如電子郵件。（Git 提供了 git-request-pull[1] 向開發人員發送預格式化的拉取請求，以簡化此任務。）

如果你只是想獲得整合分支的最新副本，保持更新也很容易：

然後按照前面解釋的那樣，從穩定的遠端分支出來你的主題分支。

如果你是維護者，並且想將其他人的主題分支合併到整合分支中，他們通常會透過電子郵件發送請求。這樣的請求看起來如下：

在這種情況下，git pull 可以一次完成獲取和合併，如下所示：

有時，維護者在嘗試從下游拉取變更時可能會遇到合併衝突。在這種情況下，他們可以要求下游自己進行合併並解決衝突（也許他們更清楚如何解決這些衝突）。這是下游應該從上游合併的少數情況之一。

如果你是以電子郵件形式將變更發送到上游的貢獻者，你應該照常使用主題分支（參見上文）。然後使用 git-format-patch[1] 來產生相應的電子郵件（強烈推薦，勝過手動格式化，因為它讓維護者的生活更輕鬆）。

參見 git-format-patch[1] 和 git-send-email[1] 手冊頁以獲取更多使用說明。

如果維護者告訴你，你的修補程式不再適用於當前上游，你將必須重定基準你的主題（你不能使用合併，因為你無法對合併結果進行 format-patch）。

然後你可以在重定基準期間修復衝突。據推測，除了透過電子郵件之外，你沒有發佈過你的主題，所以重定基準它不是問題。

如果你收到這樣的修補程式系列（作為維護者，或者作為發送到的郵件列表的讀者），請將郵件儲存到檔案中，建立一個新的主題分支，並使用 git am 來匯入提交：

值得指出的一個功能是三向合併，如果你遇到衝突，它可以提供幫助：git am -3 將使用修補程式中包含的索引資訊來找出合併基礎。參見 git-am[1] 以獲取其他選項。