3.4 Git 分支 - 分支工作流程

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

許多 Git 開發人員都採用這種工作流程，例如，只將完全穩定的程式碼儲存在其 master 分支中 — 可能是已釋出或即將釋出的程式碼。他們還有一個名為 develop 或 next 的並行分支，他們從中工作或用於測試穩定性 — 它不一定總是穩定的，但只要它達到穩定狀態，就可以合併到 master 中。當主題分支（短期分支，例如您之前的 iss53 分支）準備好時，就可以將其合併進來，以確保它們透過所有測試並且不會引入 bug。

實際上，我們討論的是指向您正在進行的提交的指標。穩定分支在您的提交歷史中位於較靠下的位置，而最新的分支則位於較靠上的位置。

通常更容易將它們視為工作隔離區，當一組提交經過充分測試後，它們就會進入更穩定的隔離區。

您可以為多個穩定性級別重複此操作。一些大型專案還有一個 proposed 或 pu（proposed updates）分支，其中包含尚未準備好合併到 next 或 master 分支的已整合分支。其理念是您的分支處於不同的穩定性級別；當它們達到更穩定的級別時，就會合併到其上方的分支中。同樣，並非必須擁有多個長期分支，但它通常很有幫助，尤其是在處理非常大或複雜的專案時。

然而，主題分支對任何規模的專案都很有用。主題分支是一個短期分支，您建立它並將其用於單個特定功能或相關工作。這可能是您以前從未對版本控制系統做過的事情，因為建立和合並分支通常成本很高。但在 Git 中，一天內建立、處理、合併和刪除分支多次是很常見的。

在上一節中，您已經看到過您建立的 iss53 和 hotfix 分支。您在上面進行了幾次提交，並在合併到主分支後立即刪除了它們。這種技術可以讓您快速而全面地切換上下文 — 因為您的工作被分成了隔離區，該分支中的所有更改都與該主題相關，因此更容易在程式碼審查等過程中瞭解發生了什麼。您可以將更改保留在那裡幾分鐘、幾天或幾個月，並在準備好時將其合併，而無論它們建立或處理的順序如何。

考慮一個例子：您正在進行一些工作（在 master 上），然後為某個問題建立一個分支（iss91），在該分支上工作一段時間，然後從第二個分支再次分支以嘗試處理同一問題的另一種方法（iss91v2），然後回到 master 分支並在此處工作一段時間，然後再次從此處分支以執行一些您不確定是否是好主意的操作（dumbidea 分支）。您的提交歷史將如下所示：

現在，假設您決定最喜歡第二個解決方案（iss91v2）；您將 dumbidea 分支展示給同事，結果發現它是個天才的想法。您可以丟棄原始的 iss91 分支（丟失提交 C5 和 C6），然後合併另外兩個。您的歷史記錄將如下所示：

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

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