現在我們已經學會了新建分支和合并分支，可以（或應該）用它來做點什么呢？在本節，我們會介紹一些利用分支進行開發的工作流程。而正是由于分支管理的便捷，才衍生出了這類典型的工作模式，你可以根據項目的實際情況選擇一種用用看。 ## 長期分支 由于 Git 使用簡單的三方合并，所以就算在較長一段時間內，反復多次把某個分支合并到另一分支，也不是什么難事。也就是說，你可以同時擁有多個開放的分支，每個分支用于完成特定的任務，隨著開發的推進，你可以隨時把某個特性分支的成果并到其他分支中。 許多使用 Git 的開發者都喜歡用這種方式來開展工作，比如僅在 master 分支中保留完全穩定的代碼，即已經發布或即將發布的代碼。與此同時，他們還有一個名為 develop 或 next 的平行分支，專門用于后續的開發，或僅用于穩定性測試 — 當然并不是說一定要絕對穩定，不過一旦進入某種穩定狀態，便可以把它合并到 master 里。這樣，在確保這些已完成的特性分支（短期分支，比如之前的 iss53 分支）能夠通過所有測試，并且不會引入更多錯誤之后，就可以并到主干分支中，等待下一次的發布。 本質上我們剛才談論的，是隨著提交對象不斷右移的指針。穩定分支的指針總是在提交歷史中落后一大截，而前沿分支總是比較靠前（見圖 3-18）。  圖 3-18. 穩定分支總是比較老舊。 或者把它們想象成工作流水線，或許更好理解一些，經過測試的提交對象集合被遴選到更穩定的流水線（見圖 3-19）。  圖 3-19. 想象成流水線可能會容易點。 你可以用這招維護不同層次的穩定性。某些大項目還會有個 proposed（建議）或 pu（proposed updates，建議更新）分支，它包含著那些可能還沒有成熟到進入 next 或 master 的內容。這么做的目的是擁有不同層次的穩定性：當這些分支進入到更穩定的水平時，再把它們合并到更高層分支中去。再次說明下，使用多個長期分支的做法并非必需，不過一般來說，對于特大型項目或特復雜的項目，這么做確實更容易管理。 ## 特性分支 在任何規模的項目中都可以使用特性（Topic）分支。一個特性分支是指一個短期的，用來實現單一特性或與其相關工作的分支。可能你在以前的版本控制系統里從未做過類似這樣的事情，因為通常創建與合并分支消耗太大。然而在 Git 中，一天之內建立、使用、合并再刪除多個分支是常見的事。 我們在上節的例子里已經見過這種用法了。我們創建了 iss53 和 hotfix 這兩個特性分支，在提交了若干更新后，把它們合并到主干分支，然后刪除。該技術允許你迅速且完全的進行語境切換 — 因為你的工作分散在不同的流水線里，每個分支里的改變都和它的目標特性相關，瀏覽代碼之類的事情因而變得更簡單了。你可以把作出的改變保持在特性分支中幾分鐘，幾天甚至幾個月，等它們成熟以后再合并，而不用在乎它們建立的順序或者進度。 現在我們來看一個實際的例子。請看圖 3-20，由下往上，起先我們在 master 工作到 C1，然后開始一個新分支 iss91 嘗試修復 91 號缺陷，提交到 C6 的時候，又冒出一個解決該問題的新辦法，于是從之前 C4 的地方又分出一個分支 iss91v2，干到 C8 的時候，又回到主干 master 中提交了 C9 和 C10，再回到 iss91v2 繼續工作，提交 C11，接著，又冒出個不太確定的想法，從 master 的最新提交 C10 處開了個新的分支 dumbidea 做些試驗。  圖 3-20. 擁有多個特性分支的提交歷史。 現在，假定兩件事情：我們最終決定使用第二個解決方案，即 iss91v2 中的辦法；另外，我們把 dumbidea 分支拿給同事們看了以后，發現它竟然是個天才之作。所以接下來，我們準備拋棄原來的 iss91 分支（實際上會丟棄 C5 和 C6），直接在主干中并入另外兩個分支。最終的提交歷史將變成圖 3-21 這樣：  圖 3-21. 合并了 dumbidea 和 iss91v2 后的分支歷史。 請務必牢記這些分支全部都是本地分支，這一點很重要。當你在使用分支及合并的時候，一切都是在你自己的 Git 倉庫中進行的 — 完全不涉及與服務器的交互。