這幾天在網上查詢了一些資料，了解到比較常見的版本控制分支策略有三種：不穩定主干策略、穩定主干策略、敏捷發布策略。
下面是對這幾種策略的摘錄：
不穩定主干策略
使用用主干作為新功能開發主線，分支用作發布。
被廣泛的應用于開源項目。
比較適合諸如傳統軟件產品的開發模式，比如微軟的office等。
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場景外應當避免。