這幾天在網(wǎng)上查詢了一些資料，了解到比較常見的版本控制分支策略有三種：不穩(wěn)定主干策略、穩(wěn)定主干策略、敏捷發(fā)布策略。
下面是對這幾種策略的摘錄：
不穩(wěn)定主干策略
使用用主干作為新功能開發(fā)主線，分支用作發(fā)布。
被廣泛的應用于開源項目。
比較適合諸如傳統(tǒng)軟件產(chǎn)品的開發(fā)模式，比如微軟的office等。
bug修改需要在各個分支中合并。
新代碼在主干上開發(fā)，因此如果主干不能達到穩(wěn)定的標準，就不可以進行發(fā)布。
這種策略的好處是沒有分支合并的工作量，因此比較簡單。
穩(wěn)定主干策略
使用主干作為穩(wěn)定版的發(fā)布。
bug的修改和新功能的增加，全部在分支上進行。
不同的修改或新功能開發(fā)以分支隔離。
分支上的開發(fā)和測試完畢以后才合并到主干。
主干上的每一次發(fā)布都做一個標簽而不是分支。
每次發(fā)布的內(nèi)容調(diào)整起來比較容易。
缺點是分支合并所增加的成本。
敏捷發(fā)布策略
敏捷開發(fā)模式的項目中廣泛采用，敏捷開發(fā)的項目具有固定的發(fā)布周期。
為每個task建立分支。
為每個發(fā)布建立分支，每個周期內(nèi)的task分支需要合并到發(fā)布分支發(fā)布。
在完成發(fā)布后，發(fā)布分支的功能合并到主干和尚在進行的任務分支中。
一種穩(wěn)定主干策略的變體。
團隊成員要求較高。
團隊當前情況
負責互聯(lián)網(wǎng)產(chǎn)品的開發(fā)，發(fā)布更新較為頻繁。
有固定的發(fā)布周期，同時也存在比較多的hotfix。
修改任務通常比較小，改動范圍通常不大，時間通常較短。
不同的功能頁面有不同的小組負責，耦合度相對較低。
團隊目前沒有采用分支策略，開發(fā)人員協(xié)商進行增量更新，出現(xiàn)錯誤的幾率較高。
已使用微軟TFS做為版本控制工具，可以更充分的挖掘使用TFS的分支功能。
我的初步實踐
參考上述策略，結合當前團隊的現(xiàn)狀，我初步設計了下面的版本控制解決方案。
此方案已穩(wěn)定主干策略為主結合了一些敏捷發(fā)布策略的思路，具體實施方案如下：
1、主干時刻處于穩(wěn)定狀態(tài)，隨時可以發(fā)布。設專門人員對主干代碼進行管理，普通開發(fā)人員只讀。
2、為開發(fā)任務建立開發(fā)分支。常規(guī)的可以以小組為單位建立分支，較大的任務可以建立專門的分支。
3、在發(fā)布日，從主干復制一個測試分支，需要在本發(fā)布日發(fā)布的各開發(fā)分支向此測試分支合并。
4、對測試分支代碼進行測試，出現(xiàn)bug在測試分支上更改，無誤后發(fā)布。
5、測試分支代碼發(fā)布后，合并入主干，并在主干上進行標記。
6、對緊急修復（Hotfix）的情況，可以從主干復制出測試分支，在測試分支上進行緊急修改，并在測試后發(fā)布，發(fā)布后同樣將代碼合并會主干，做標記。
7、 Hotfix僅限于可以很快解決的小問題，如果更改時間過長，則需采用常規(guī)方法完成。
8、如果在測試分支測試過程中需要hotfix工作，則在復制一個新的測試分支進行hotfix，測試后發(fā)布。然后同時合并入原測試分支和主干，并在主干上做標記。此過程未在上圖中畫出。
9、測試分支發(fā)布后，開發(fā)分支可以刪除；測試分支合并入主干后，測試分支可以定期刪除。
方案的優(yōu)缺點
方案優(yōu)點
1、解決了沒有實施分支策略時，代碼不能經(jīng)常簽入的問題。
2、主干代碼始終處于穩(wěn)定的狀態(tài)隨時可以發(fā)布，降低了風險。
3、可以基于一個完整的測試分支進行測試及發(fā)布，而不是以口口相傳的方式增量更新。
方案缺點
1、建立分支、合并分支增加了工作量?？紤]實際情況，以及版本控制工具的輔助，增加的工作量應該可以接受。
2、如果某些開發(fā)分支工期跨越多個發(fā)布周期，修改過于劇烈，合并分支時可能工作量較大?？梢钥紤]分解任務，避免過大的任務出現(xiàn)。
3、在同一時間最好只有一個測試分支，因此建立測試分支的權限需要限制，除hotfix場景外應當避免。