簡單和重複的特性帶來的結果是：分支與合并不再是什麼可以害怕的東西。分支/合并被認為對于版本管理工具比其他功能更重要。
關于工具，不再多說，讓我們直接看開發模型吧。這個模型并不是如下模型：在管理軟體開發進度方面，面對每個開發過程，每個隊員必須按一定次序開發。
對于這種分支模型，我們設定了一個版本庫，它運轉良好，這是一個”事實上” 版本庫。不過請注意，這個版本庫隻是被認為是中心版本庫（因為git是一個分布式版本管理系統，從技術上來講，并沒有一個中心版本庫）。我們将把這個版本庫稱為原始庫，這個名字對所有的git使用者來說都很容易了解。
每個開發者都對origin庫拉代碼和送出代碼。但是除了集中式的存取代碼關系，每個開發者也可以從子團隊的其他隊友那裡獲得代碼版本變更。例如，對于2個或多個開發者一起完成的大版本變更，為了防止過早地向origin庫送出工作内容，這種機制就變得非常有用。在上述途中，有如下子團隊：alice和bob，alice和david，clair和david。
從技術上将，這意味着，alice建立了一個git的遠端節點，而對于bob，該節點指向了bob的版本庫，反之亦然。
在核心部分，研發模型很大程度上靠其他現有模型支撐的。中心庫有2個可一直延續的分支：
master分支
develop分支
每個git使用者都要熟悉原始的master分支。與master分支并行的另一個分支，我們稱之為develop分支。
我們把原始庫/master庫認作為主分支，head的源代碼存在于此版本中，并且随時都是一個預備生産狀态。
我們把origin/develop庫認為是主分支，該分支head源碼始終展現下個釋出版的最新軟體變更。有人稱這個為“內建分支”，而這是每晚自動建構得來的。
當develop分支的源碼到達了一個穩定狀态待釋出，所有的代碼變更需要以某種方式合并到master分支，然後标記一個版本号。如何操作将在稍後詳細介紹。
是以，每次變更都合并到了master，這就是新産品的定義。在這一點，我們傾向于嚴格執行這一點，進而，理論上，每當對master有一個送出操作，我們就可以使用git鈎子腳本來自動建構并且釋出軟體到生産伺服器。
我們的開發模型使用了各種輔助性分支，這些分支與關鍵分支（master和develop）一起，用來支援團隊成員們并行開發，使得易于追蹤功能，協助生産釋出環境準備，以及快速修複實時線上問題。與關鍵分支不同，這些分支總是有一個有限的生命期，因為他們最終會被移除。
我們用到的分支類型包括：
功能分支
釋出分支
熱修複分支
每一種分支有一個特定目的，并且受限于嚴格到規則，比如：可以用哪些分支作為源分支，哪些分支能作為合并目标。我們馬上将進行演練。
從技術角度來看，這些分支絕不是特殊分支。分支的類型基于我們使用的方法來進行分類。它們理所當然是普通的git分支。
可能是develop分支的分支版本，最終必須合并到develop分支中。
分支命名規則：除了master、develop、release-*、hotfix-*之外，其他命名均可。
功能分支（有時被稱為topic分支）通常為即将釋出或者未來釋出版開發新的功能。當新功能開始研發，包含該功能的釋出版本在這個還是無法确定釋出時間的。功能版本的實質是隻要這個功能處于開發狀态它就會存在，但是最終會或合并到develop分支（确定将新功能添加到不久的釋出版中）或取消（譬如一次令人失望的測試）。
功能分支通常存在于開發者的軟體庫，而不是在源代碼庫中。
開始一項功能的開發工作時，基于develop建立分支。
完成的功能可以合并進develop分支，以明确加入到未來的釋出：
–no-ff标志導緻合并操作建立一個新commit對象，即使該合并操作可以fast-forward。這避免了丢失這個功能分支存在的曆史資訊，将該功能的所有送出組合在一起。 比較:
後一種情況，不可能從git曆史中看到哪些送出一起實作了一個功能——你必須手工閱讀全部的日志資訊。如果對整個功能進行回退 (比如一組送出)，後一種方式會是一種真正頭痛的問題，而使用–no-ff參數的情況則很容易.
是的，它會建立一個新的（空）送出對象，但是收益遠大于開銷。
不幸的是，我還沒找到一種方法，讓–no-ff時作為合并操作的預設選項，但它應該是可行的。
release分支可能從develop分支分離而來，但是一定要合并到develop和master分支上，它的習慣命名方式為：release-*。
release分支是為新産品的釋出做準備的。它允許我們在最後時刻做一些細小的修改。他們允許小bugs的修改和準備釋出中繼資料（版本号，開發時間等等）。當在release分支完成這些所有工作以後，對于下一次打的釋出，develop分支接收features會更加明确。
從develop分支建立新的release分支的關鍵時刻是develop分支達到了釋出的理想狀态。至少所有這次要釋出的features必須在這個點及時合并到develop分支。對于所有未來準備釋出的features必須等到release分支建立以後再合并。
在release分支建立的時候要為即将發行版本配置設定一個版本号，一點都不早。直到那時，develop分支反映的變化都是為了下一個發行版，但是在release分支建立之前，下一個發行版到底叫0.3還是1.0是不明确的。這個決定是在release分支建立時根據項目在版本号上的規則制定的。
release分支是從develop分支建立的。例如，目前産品的發行版本号為1.1.5，同僚我們有一個大的版本即将發行。develop 分支已經為下次發行做好了準備，我們得決定下一個版本是1.2（而不是1.1.6或者2.0）。是以我們将release分支分離出來，給一個能夠反映新版本号的分支名。
建立新分支以後，切換到該分支，添加版本号。這裡，bump-version.sh 是一個虛構的shell腳本，它可以複制一些檔案來反映新的版本（這當然可以手動改變–目的就是修改一些檔案）。然後版本号被送出。
這個新分支可能會存在一段時間，直到該發行版到達它的預定目标。在此期間，bug的修複可能被送出到該分支上（而不是送出到develop分支上）。在這裡嚴格禁止增加大的新features。他們必須合并到develop分支上，然後等待下一次大的發行版。
當一個release分支準備好成為一個真正的發行版的時候，有一些工作必須完成。首先，release分支要合并到master上（因為每一次送出到master上的都是一個新定義的發行版，記住）。然後，送出到master上必須打一個标簽，以便以後更加友善的引用這個曆史版本。最後，在release分支上的修改必須合并到develop分支上，以便未來發行版也包含這些bugs的修複。
在git中的前兩步是：
發行版現在已經完成，為以後引用打上标簽。
修訂：你可能也想使用-s或-u 參數來标記你的标簽。
為了是修改保持在release分支上，我們需要合并這些到develop分支上去，在git上：
這個步驟可能會導緻合并沖突（可能由于改變版本号更是如此）。如果是這樣，修複它然後送出。
現在我們真正的完成了，這個release分支将被删除，因為我們不再需要它了。
可以基于master分支，必須合并回develop和master分支。
分支名約定：hotfix-*
熱修複分支與釋出分支很相似，他們都為新的生成環境釋出做準備，盡管這是未經計劃的。他們來自生産環境的處于異常狀态壓力。當生成環境驗證缺陷必須馬上修複是，熱修複分支可以基于master分支上對應與線上版本的tag建立。
其本質是團隊成員（在develop分支上）的工作可以繼續，而另一個人準備生産環境的快速修複。
hotfix branch(修補bug分支)是從master分支上面分出來的。例如，1.2版本是目前生産環境的版本并且有bug。但是開發分支（develop）變化還不穩定。我們需要分出來一個修補bug分支（hotfix branch）來解決這種情況。
分支關閉的時侯不要忘了更新版本号(bump the version)
然後，修複bug，一次送出或者多次分開送出。
完成一個bugfix之後，需要把bugfix合并到master和develop分支去，這樣就可以保證修複的這個bug也包含到下一個發行版中。這一點和完成release分支很相似。
首先，更新master并對release打上tag：
下一步，把bugfix添加到develop分支中：
規則的一個例外是：如果一個release分支已經存在，那麼應該把hotfix合并到這個release分支，而不是合并到develop分支。當release分支完成後， 将bugfix分支合并回release分支也會使得bugfix被合并到develop分支。（如果在develop分支的工作急需這個bugfix，等不到release分支的完成，那你也可以把bugfix合并到develop分支）
最後，删除臨時分支：
盡管這個分支模型沒有任何震撼的新東西, 文章開頭的圖表在我們的項目中表現出驚人的實用性。它形成了一個優雅的思維模型，易于領悟并使團隊成員發展出對分支和釋出過程的共同了解。
這裡提供一份高品質pdf格式圖表。去吧，把它挂載牆上以便能随時快速參考。