現在我們已經學會了新建分支和合併分支，可以（或應該）用它來做點什麼呢？在本節，我們會介紹一些利用分支進行開發的工作流程。而正是由於分支管理的便捷，才衍生出了這類典型的工作模式，你可以根據專案的實際情況選擇一種用用看。
由於 git 使用簡單的三方合併，所以就算在較長一段時間內，反覆多次把某個分支合併到另一分支，也不是什麼難事。也就是說，你可以同時擁有多個開放的分支，每個分支用於完成特定的任務，隨著開發的推進，你可以隨時把某個特性分支的成果並到其他分支中。
本質上我們剛才談論的，是隨著提交物件不斷右移的指標。穩定分支的指標總是在提交歷史中落後一大截，而前沿分支總是比較靠前（見圖 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 倉庫中進行的 — 完全不涉及與伺服器的互動。
Git 分支 利用分支進行開發的工作流程
3.4 git 分支 利用分支進行開發的工作流程 利用分支進行開發的工作流程 現在我們已經學會了新建分支和合併分支，可以 或應該 用它來做點什麼呢？在本節，我們會介紹一些利用分支進行開發的工作流程。而正是由於分支管理的便捷，才衍生出了這類典型的工作模式，你可以根據專案的實際情況選擇一種用用看。長期分...
Git建立分支進行開發
一 業務場景 自己當前開發的專案算是乙個中型專案，整個專案都是由自己乙個人開發完成，主要有兩個子專案，乙個是小程式的後台，乙個是小程式的後台管理系統。因為從一開始就只有我乙個人在進行開發，所以自己平時提交 的時候都是提交到主幹，也沒有建立分支，管理也沒出現什麼問題。現在專案已經穩定執行 幾個月，相對...
Git分支 master分支和開發版本分支
問題 在使用git時，假如遠端倉庫有dev和master兩個分支，master作為乙個穩定版分支，可用於直接發布產品，日常的開發則push到dev分支，那本地是不是要從dev分支中建立乙個本地分支，然後在這個分支的push的動作是預設推到遠端dev分支上？解惑 一 遠端倉庫有master和dev分支...