作者：張克強 作者微博：張克強-敏捷307
1，先鋒主干多穩定分支；2，守護主干多先鋒分支。3，主干無分支；4。守護主干單分支。
一、先鋒主干多穩定分支
得到一個穩定版本號后。將此穩定版本號放到一個新分支上，針對此穩定版本號的修修補補就在這個分支上進行。新功能不在此分支上開發。而在主干上進行新功能的開發。 這是業界採用較多的模式。
穩定分支上的有些改動。比方缺陷修復，須要合並到主干。 但有些特定改動，是不須要合並到主干的。這時須要千萬注意，合並准確的文件到主干。
對於不能合並到主干的情況，常見的是再拉一個分支。這個分支專門為少數特定情況而用，但從全局講，可能會導致太多分支。不同分支間混亂，所以這並不推薦。推薦寧願採用配置開關。
圖片來源於 http://blog.csdn.net/binnacler/article/details/4274486
比方freebsd的公布就是一個典型的樣例。
freebsd的主干永遠是current，也就是包含全部最新特性的不穩定版本號。然后隨着新特性的逐步穩定，達到一個公布的里程碑以后，從主干分出來一個stable分支。
freebsd是每一個大版本號一個分支。
也就是說4.x，5.x。6,x各一個分支。每一個公布分支上僅僅有bug改動和現有功能的完好。而不會再添加新特性。
新特性會繼續在主干上開發。當穩定分支上發生的改動積累到一定程度以后。就會有一次公布。公布的時候會在穩定分支上再分出來一個 release分支。
以6.x為例，就會有6.0,6.1,6.2…等公布分支。【此段摘自於網絡 http://thinkernel.bokee.com/4518935.html 】
二、守護主干多先鋒分支
當先鋒分支通過一定的測試之后，合並到主干。能夠同一時候有多個先鋒分支，不同的功能能夠拉不同的分支，不同公布時間點而又要同一時候開發的內容必須在不同的分支上。
而對主干上的每一次公布都做一個標簽而不是分支。分支上的開發和測試完畢以后才合並到主干。
這樣的公布方法的優點是每次公布的內容調整起來比較easy。
假設某個新功能或者bug在下一次公布之前無法完畢，就不可能合並到主干。也就不會影響其它變更的公布。
另外，每一個分支的生命期比較短，唯一長期存在的就是主干。這樣每次合並的風險非常小。每次公布之前，僅僅要比較主干上的最新版本號和上一次公布的版本號就能夠知道這次公布的文件范圍了。
三、主干無分支
單從效率講。這是最高效的模式了。要有不少配套措施才干夠。常見的配套措施：每日集成（編譯部署測試），靜態代碼檢查，測試不僅僅有單元測試，還有接口測試。還有界面自己主動化測試。
四、守護主干單分支
須要採用與主干無分支同樣的配套手段。並且在主干和分支上都須要建設每日集成。甚至持續集成。