現在你已經熟練了分支（branch）和合併（merge）的基本用法，那麼你能夠或者你應該把它們拿來做些什麼呢？ 在這一節中，我們將會介紹一些得益於輕便的分支功能而常見的工作流程，接著你可以自己決定是否想要將它們整併到你的開發循環中。
由於 Git 使用簡單的三方合併（three-way merge），所以就算在一段較長的時間內，反覆把一個分支合併入另一個分支，也不是什麼難事； 也就是說，你可以擁有一些開放的長期（long-running）分支，分別用於開發循環中不同階段的任務，並且可以經常性地把某些分支合併到其他分支中。
許多 Git 開發者都喜歡用這種方式來工作，比如只在 master 分支中保持完全穩定的程式碼——亦即已經發行或即將發行的程式碼；
他們還會有其它平行的長期分支，像是 develop 用於後續的開發，或者 next 用於測試穩定性——這種分支並不一定要一直保持穩定性，不過一旦進入穩定狀態，便可以把它合併到 master 裡；
它也被用來引進已完成的主題分支（短期分支，比如之前的 iss53 分支），並確保它們能通過測試而不會引入臭蟲。
實際上，我們談論的是隨著提交（commit）不斷線性向前移動的指標； 在提交歷史中，穩定分支總是落後一大截，而前沿分支則是超前一大截。
一般而言，把它們想像成工作流水線會比較好理解，當這些提交經過完整的測試後便可以前進到更穩定的流水線中。
你可以不斷地用這種方式擴展出更多層次的穩定性，
像是某些大型專案還會有一個 proposed 或 pu（proposed updates）分支，它會整合那些可能還沒有準備好進入 next 或 master 的分支；
而所使用的概念就是讓這些分支處於不同層次的穩定性：當這些分支進入到更穩定的水準時，再把它們合併到更高層的分支。
再次說明，使用多個長期分支的做法並非必需，但是對於特別大型或者複雜的專案而言是有幫功的。
然而，在任何規模的專案中使用主題（topic）分支都是有用的； 它是一種短期的分支，用來實現單一特性或相關工作； 這是你可能從未在之前的 VCS 中做過的事情，因為建立與合併分支開銷通常太大； 但是在 Git 中，一天之內多次地建立、使用、合併，和刪除分支是常見的事。
你已見識過在上一節中所建立的 iss53 和 hotfix 分支便是這樣的用法：
在這二支個分支上做了一些提交，並在合併到主分支後刪除它們；
該技術可以讓你迅速地且完整地進行內容切換——因為你的工作被隔離在不同的流水線中，使得該分支裡的所有變更都只和它的主題相關；並且在諸如程式碼審核的過程中，它也讓檢視修改內容變得更簡單了；
你可以在主題分支中保留修改的內容幾分鐘、幾天，或幾個月，等它們準備好之後再將它們合併，而不用在乎它們被建立或工作的順序。
來看一個例子！一開始在 master 上工作（譯註：來到 C1），然後為了一個議題切換到分支 iss91 上工作一會兒（譯註：C2、C4～C6）；由於想嘗試用另一種方法來解決相同的議題，於是使用 iss91v2 分支重新展開工作（譯註：回到 C4 再展開新的工作 C7、C8、C11）；之後又回到 master 工作了一段時間（譯註：一路來到 C10），接著腦中有個不太確定的想法，於是再建立一個新的分支 dumbidea 做了一些工作（譯註：C12、C13）。
你的提交歷史看起來像這樣：
現在，你決定使用第二個方案（iss91v2）來解決議題；你也把分支 dumbidea 的工作內容展示給同事們看之後，發現它是個天才之作；
接下來，你可以丟棄原來的 iss91 分支（會失去提交 C5 和 C6），然後把那二個分支合併進入 master 分支。
提交歷史將變成這樣：
dumbidea 和 iss91v2 後的歷史我們將在 [_distributed_git] 詳細地介紹各種 Git 專案可能的工作流程，所以在你下次的專案決定採用哪一種分支使用規劃之前，記得閱讀那一章。
有一點很重要請牢記：這些分支全部都是本地分支； 當你在使用分支及合併時，一切都是在你自己的 Git 版本庫中進行的——完全不涉及與伺服器的通訊。