下面是對這幾種政策的摘錄：
不穩定主幹政策
使用用主幹作為新功能開發主線，分支用作釋出。
被廣泛的應用于開源項目。
bug修改需要在各個分支中合并。
新代碼在主幹上開發，是以如果主幹不能達到穩定的标準，就不可以進行釋出。
穩定主幹政策
使用主幹作為穩定版的釋出。
bug的修改和新功能的增加，全部在分支上進行。
不同的修改或新功能開發以分支隔離。
主幹上的每一次釋出都做一個标簽而不是分支。
每次釋出的内容調整起來比較容易。
缺點是分支合并所增加的成本。
靈活釋出政策
靈活開發模式的項目中廣泛采用，靈活開發的項目具有固定的釋出周期。
為每個task建立分支。
為每個釋出建立分支，每個周期内的task分支需要合并到釋出分支釋出。
在完成釋出後，釋出分支的功能合并到主幹和尚在進行的任務分支中。
一種穩定主幹政策的變體。
團隊成員要求較高。
團隊目前情況
負責網際網路産品的開發，釋出更新較為頻繁。
有固定的釋出周期，同時也存在比較多的hotfix。
修改任務通常比較小，改動範圍通常不大，時間通常較短。
不同的功能頁面有不同的小組負責，耦合度相對較低。
團隊目前沒有采用分支政策，開發人員協商進行增量更新，出現錯誤的幾率較高。
已使用微軟tfs做為版本控制工具，可以更充分的挖掘使用tfs的分支功能。
我的初步實踐
參考上述政策，結合目前團隊的現狀，我初步設計了下面的版本控制解決方案。
此方案已穩定主幹政策為主結合了一些靈活釋出政策的思路，具體實施方案如下：
1、主幹時刻處于穩定狀态，随時可以釋出。設專門人員對主幹代碼進行管理，普通開發人員隻讀。
2、為開發任務建立開發分支。正常的可以以小組為機關建立分支，較大的任務可以建立專門的分支。
3、在釋出日，從主幹複制一個測試分支，需要在本釋出日釋出的各開發分支向此測試分支合并。
4、對測試分支代碼進行測試，出現bug在測試分支上更改，無誤後釋出。
5、測試分支代碼釋出後，合并入主幹，并在主幹上進行标記。
6、對緊急修複（hotfix）的情況，可以從主幹複制出測試分支，在測試分支上進行緊急修改，并在測試後釋出，釋出後同樣将代碼合并會主幹，做标記。
7、 hotfix僅限于可以很快解決的小問題，如果更改時間過長，則需采用正常方法完成。
8、如果在測試分支測試過程中需要hotfix工作，則在複制一個新的測試分支進行hotfix，測試後釋出。然後同時合并入原測試分支和主幹，并在主幹上做标記。此過程未在上圖中畫出。
9、測試分支釋出後，開發分支可以删除；測試分支合并入主幹後，測試分支可以定期删除。
方案的優缺點
方案優點
1、解決了沒有實施分支政策時，代碼不能經常簽入的問題。
2、主幹代碼始終處于穩定的狀态随時可以釋出，降低了風險。
3、可以基于一個完整的測試分支進行測試及釋出，而不是以口口相傳的方式增量更新。
方案缺點
1、建立分支、合并分支增加了工作量。考慮實際情況，以及版本控制工具的輔助，增加的工作量應該可以接受。
2、如果某些開發分支工期跨越多個釋出周期，修改過于劇烈，合并分支時可能工作量較大。可以考慮分解任務，避免過大的任務出現。
3、在同一時間最好隻有一個測試分支，是以建立測試分支的權限需要限制，除hotfix場景外應當避免。
====================================分割線================================
最新内容請見作者的github頁：http://qaseven.github.io/