3.4 Git 分支 - 分支工作流程

由於 Git 使用簡單的三向合併，因此在較長的時間內多次將一個分支合併到另一個分支通常很容易做到。這表示您可以有多個總是開啟的分支，並將它們用於開發週期的不同階段；您可以定期從某些分支合併到其他分支。

許多 Git 開發人員採用這種方法的工作流程，例如僅在其 master 分支中擁有完全穩定的程式碼 — 可能僅是已經發佈或將要發佈的程式碼。他們還有另一個平行分支，名稱為 develop 或 next，他們從該分支工作或用它來測試穩定性 — 它不一定總是穩定，但只要它達到穩定狀態，就可以合併到 master 中。它用於在主題分支（短暫的分支，就像您先前的 iss53 分支）準備就緒時將其拉入，以確保它們通過所有測試並且不會引入錯誤。

實際上，我們談論的是指標沿著您所做的提交線向上移動。穩定的分支在提交歷史記錄中更靠後，而前沿分支在歷史記錄中更靠前。

通常將它們視為工作倉儲更容易，其中當提交完全測試後，提交組會升級到更穩定的倉儲。

您可以針對多個穩定性級別執行此操作。一些較大的專案還有一個 proposed 或 pu (proposed updates) 分支，該分支已整合了可能尚未準備好進入 next 或 master 分支的分支。這個想法是您的分支處於不同的穩定性級別；當它們達到更穩定的級別時，它們會合併到它們上方的分支中。同樣，擁有多個長期運行分支不是必需的，但通常很有幫助，尤其是在您處理非常大型或複雜的專案時。

但是，主題分支在任何規模的專案中都很有用。主題分支是一個短暫的分支，您建立並將其用於單一特定功能或相關工作。這是在 Git 之前，您可能從未在 VCS 中做過的事情，因為建立和合併分支通常太昂貴。但是在 Git 中，每天建立、工作、合併和刪除分支是很常見的事情。

您在上一節中已經看過這種情況，當時您建立了 iss53 和 hotfix 分支。您在這些分支上進行了一些提交，並在將它們合併到主分支後立即刪除它們。這種技術讓您可以快速且完全地切換上下文 — 因為您的工作被劃分到不同的「筒倉」中，每個分支中的所有變更都與該主題相關，因此更容易查看程式碼審查期間發生的事情。您可以將變更保留在那裡幾分鐘、幾天或幾個月，並在它們準備好時合併它們，而無需考慮它們的創建或工作順序。

考慮一個例子：在 master 上進行一些工作，然後為一個問題分支出去 (iss91)，處理一段時間，再從第二個分支分支出去，嘗試另一種處理相同事情的方式 (iss91v2)，回到您的 master 分支並在那裡工作一段時間，然後從那裡分支出去，進行一些您不確定是否是好主意的工作 (dumbidea 分支)。您的提交歷史記錄會如下所示：

現在，假設您決定最喜歡您的問題的第二個解決方案 (iss91v2)；並且您向同事展示了 dumbidea 分支，結果發現它很棒。您可以丟棄原始的 iss91 分支（丟失提交 C5 和 C6），並合併其他兩個分支。您的歷史記錄將如下所示：

我們將在分散式 Git中更詳細地介紹 Git 專案的各種可能的工作流程，因此在您決定下一個專案將使用哪種分支方案之前，請務必閱讀該章。

重要的是要記住，當您進行所有這些操作時，這些分支完全是本地的。當您進行分支和合併時，一切都只在您的 Git 儲存庫中完成 — 不會與伺服器進行任何通信。