3.4 Git 分支 - 分支工作流

由於 Git 使用簡單的三方合併，因此在很長一段時間內將一個分支多次合併到另一個分支通常很容易實現。這意味著你可以擁有多個始終處於開放狀態的分支，並將它們用於開發週期的不同階段；你可以定期將其中一些分支合併到其他分支中。

許多 Git 開發者採用一種擁抱這種方法的工作流，例如他們的 master 分支中只包含完全穩定的程式碼——可能只是已經發布或將要釋出的程式碼。他們還有另一個並行的分支，名為 develop 或 next，他們從這個分支開始工作或用於測試穩定性——它不一定總是穩定的，但只要它達到穩定狀態，就可以合併到 master 中。它用於在主題分支（短期分支，如你之前的 iss53 分支）準備就緒時將其拉入，以確保它們透過所有測試並且不引入錯誤。

實際上，我們談論的是指標在你所做的提交線上向上移動。穩定分支在你的提交歷史中靠下，而最前沿的分支則在歷史中靠上。

通常更容易將它們視為工作“筒倉”（silo），當一系列提交經過充分測試後，就會“畢業”到更穩定的筒倉中。

你可以持續進行這種多級穩定性劃分。一些大型專案還擁有一個 proposed 或 pu（proposed updates，提議更新）分支，該分支集成了可能尚未準備好進入 next 或 master 分支的子分支。其思想是你的分支處於不同的穩定性級別；當它們達到更穩定的級別時，就會合併到其上方的分支中。再次強調，擁有多個長期分支並非必需，但通常很有幫助，特別是當你處理非常大型或複雜的專案時。

然而，主題分支在任何規模的專案中都很有用。主題分支是一種短期分支，你建立它並用於單個特定功能或相關工作。這可能是你以前從未在版本控制系統（VCS）中做過的事情，因為通常建立和合並分支的成本太高。但在 Git 中，每天建立、工作、合併和刪除分支是司空見慣的。

你在上一節中看到了你建立的 iss53 和 hotfix 分支。你在它們上面做了幾次提交，並在合併到主分支後直接刪除了它們。這種技術允許你快速徹底地切換上下文——因為你的工作被分離到“筒倉”中，其中該分支中的所有更改都與該主題相關，因此在程式碼審查等過程中更容易看出發生了什麼。你可以將這些更改保留數分鐘、數天或數月，並在它們準備就緒時將其合併，無論它們建立或工作的順序如何。

考慮一個例子：你在 master 分支上做了一些工作，然後為了一個問題（iss91）建立了一個新分支，工作了一段時間，接著從第二個分支（iss91v2）再次建立分支以嘗試另一種處理相同問題的方法，然後回到你的 master 分支並工作了一段時間，再從那裡建立一個你不確定是否是個好主意的工作（dumbidea 分支）。你的提交歷史將看起來像這樣：

現在，假設你決定你最喜歡解決問題的第二個方案（iss91v2）；並且你向同事展示了 dumbidea 分支，結果證明它是個天才的想法。你可以拋棄原始的 iss91 分支（丟失提交 C5 和 C6），併合並其他兩個分支。你的歷史將看起來像這樣：

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

重要的是要記住，當你進行所有這些操作時，這些分支是完全本地的。當你進行分支和合並時，所有操作都只在你的 Git 倉庫中進行——沒有與伺服器的通訊。