# 分支開發工作流 現在你已經學會新建和合并分支，那么你可以或者應該用它來做些什么呢？在本節，我們會介紹一些常見的利用分支進行開發的工作流程。而正是由于分支管理的便捷，才衍生出這些典型的工作模式，你可以根據項目實際情況選擇一種用用看。 ## 長期分支 因為 Git 使用簡單的三方合并，所以就算在一段較長的時間內，反復把一個分支合并入另一個分支，也不是什么難事。也就是說，在整個項目開發周期的不同階段，你可以同時擁有多個開放的分支；你可以定期地把某些特性分支合并入其他分支中。 許多使用 Git 的開發者都喜歡使用這種方式來工作，比如只在 `master` 分支上保留完全穩定的代碼——有可能僅僅是已經發布或即將發布的代碼。他們還有一些名為 `develop` 或者 `next` 的平行分支，被用來做后續開發或者測試穩定性——這些分支不必保持絕對穩定，但是一旦達到穩定狀態，它們就可以被合并入 `master` 分支了。這樣，在確保這些已完成的特性分支（短期分支，比如之前的 `iss53` 分支）能夠通過所有測試，并且不會引入更多 bug 之后，就可以合并入主干分支中，等待下一次的發布。 事實上我們剛才討論的，是隨著你的提交而不斷右移的指針。穩定分支的指針總是在提交歷史中落后一大截，而前沿分支的指針往往比較靠前。  Figure 3-18. 漸進穩定分支的線性圖 通常把他們想象成流水線（work silos）可能更好理解一點，那些經過測試考驗的提交會被遴選到更加穩定的流水線上去。  Figure 3-19. 漸進穩定分支的流水線（“silo”）視圖 你可以用這種方法維護不同層次的穩定性。一些大型項目還有一個 `proposed`（建議） 或 `pu: proposed updates`（建議更新）分支，它可能因包含一些不成熟的內容而不能進入 `next` 或者 `master` 分支。這么做的目的是使你的分支具有不同級別的穩定性；當它們具有一定程度的穩定性后，再把它們合并入具有更高級別穩定性的分支中。再次強調一下，使用多個長期分支的方法并非必要，但是這么做通常很有幫助，尤其是當你在一個非常龐大或者復雜的項目中工作時。 ## 特性分支 特性分支對任何規模的項目都適用。特性分支是一種短期分支，它被用來實現單一特性或其相關工作。也許你從來沒有在其他的版本控制系統（`VCS`）上這么做過，因為在那些版本控制系統中創建和合并分支通常很費勁。然而，在 Git 中一天之內多次創建、使用、合并、刪除分支都很常見。 你已經在上一節中你創建的 `iss53` 和 `hotfix` 特性分支中看到過這種用法。你在上一節用到的特性分支（`iss53` 和 `hotfix` 分支）中提交了一些更新，并且在它們合并入主干分支之后，你又刪除了它們。這項技術能使你快速并且完整地進行上下文切換（context-switch）——因為你的工作被分散到不同的流水線中，在不同的流水線中每個分支都僅與其目標特性相關，因此，在做代碼審查之類的工作的時候就能更加容易地看出你做了哪些改動。你可以把做出的改動在特性分支中保留幾分鐘、幾天甚至幾個月，等它們成熟之后再合并，而不用在乎它們建立的順序或工作進度。 考慮這樣一個例子，你在 `master` 分支上工作到 `C1`，這時為了解決一個問題而新建 `iss91` 分支，在 `iss91` 分支上工作到 `C4`，然而對于那個問題你又有了新的想法，于是你再新建一個 `iss91v2` 分支試圖用另一種方法解決那個問題，接著你回到 `master` 分支工作了一會兒，你又冒出了一個不太確定的想法，你便在 `C10` 的時候新建一個 `dumbidea` 分支，并在上面做些實驗。你的提交歷史看起來像下面這個樣子：  Figure 3-20. 擁有多個特性分支的提交歷史 現在，我們假設兩件事情：你決定使用第二個方案來解決那個問題，即使用在 `iss91v2` 分支中方案；另外，你將 `dumbidea` 分支拿給你的同事看過之后，結果發現這是個驚人之舉。這時你可以拋棄 `iss91` 分支（即丟棄 `C5` 和 `C6` 提交），然后把另外兩個分支合并入主干分支。最終你的提交歷史看起來像下面這個樣子：  Figure 3-21. 合并了 `dumbidea` 和 `iss91v2` 分支之后的提交歷史 我們將會在 [Chapter?5](#) 中向你揭示更多有關分支工作流的細節，因此，請確保你閱讀完那個章節之后，再來決定你的下個項目要使用什么樣的分支策略（branching scheme）。 請牢記，當你做這么多操作的時候，這些分支全部都存于本地。當你新建和合并分支的時候，所有這一切都只發生在你本地的 Git 版本庫中 —— 沒有與服務器發生交互。