對於常見的git型別的**庫而言，有兩種主流的託管平台，一種是gerrit，另一種是類github的工作流程（包括bitbucket, gitlab）。
對於gerrit的模式來說，小團隊（20人以內的），可以直接在master上提交（比如martin flower一開始說的每天在mailine上提交），gerrit只是生成乙個需要merge的patch.而github一般而言只需要在master上release tag即可。另外單獨建立乙個新的dev分支，用於每天的**提交，充當了部分master的職能。比如提出的模型。
對於web開發而言，如果乙個ui feature 的週期還長於當前release cycle的週期，那麼可以使用feature toggle的技術去處理。這樣減少了維護乙個長週期feature分支的成本，並且大家仍然可以在mailine上提交**去進行持續整合。feature toggles應該是 short-lived,否則也有可能會造成生產效率的下降。
1.martin flower給持續整合的定義：
2.比較全的一篇，描述了短週期，長週期以及按照模組和特性來工作的軟體開發模式對應的分支模型。
3.常見的一種github模型：
下面這篇講了feature toggle的使用場景，儲存方式，pros and cons.
CI CD 持續整合分支模型
ci cd 持續整合分支模型 1.git flow 優勢 1 隔離性好，所有功能都有對應分支，開發和測試工作互相不干擾，發布程序不受其他未開發功能干擾 2 分支職責明確 對應分支做對應的事情 缺點 1 整合週期過長，同時又大功能在各自分支上開發，每個功能開發周期都不短 功能分支間的合併與整合十分痛苦...
如何使用企業持續整合成熟度模型？
所有團隊在四個維度都達到統一的企業持續整合成熟度 是很困難的。企業持續整合在不同的條件和狀態下，應該考慮選擇不同的方向來實現或加強。為了表明這一點，下面是乙個企業的例子，提供了企業持續整合混合成熟度的解決方法。emeno 投資公司 平衡敏捷與控制 現狀分析 emeno採納企業持續整合的最高優先順序是...
更多的特性分支意味著更少的持續整合
很多團隊現在都默默地放棄了持續整合，原因是進行特性分支更容易，基於主幹的開發欠公升值，steve smith說。在agile tour london 2015上，他將討論持續整合的死亡。infoq採訪了steve smith，關於不同分支的方法，以及他們如何與持續整合相結合，還有為什麼構建功能分支會...