這幾天在網上查詢了一些資料，了解到比較常見的版本控制分支策略有三種：不穩定主幹策略、穩定主幹策略、敏捷發布策略。
下面是對這幾種策略的摘錄：
不穩定主幹策略
使用用主幹作為新功能開發主線，分支用作發布。
被廣泛的應用於開源專案。
比較適合諸如傳統軟體產品的開發模式，比如微軟的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場景外應當避免。
***********************************=分割線******************************==
版本控制的分支策略及初步實踐
這幾天在網上查詢了一些資料，了解到比較常見的版本控制 分支策略有三種 不穩定主幹策略 穩定主幹策略 敏捷 發布策略。下面是對這幾種策略的摘錄 不穩定主幹策略 使用用主幹作為新功能開發主線，分支用作發布。被廣泛的應用於開源專案。比較適合諸如傳統軟體產品的開發模式，比如微軟 的office等。bug修改...
版本控制的分支策略及初步實踐
這幾天在網上查詢了一些資料，了解到比較常見的版本控制分支策略有三種 不穩定主幹策略 穩定主幹策略 敏捷發布策略。下面是對這幾種策略的摘錄 不穩定主幹策略 使用用主幹作為新功能開發主線，分支用作發布。被廣泛的應用於開源專案。比較適合諸如傳統軟體產品的開發模式，比如微軟的office等。bug修改需要在...
版本控制的極佳實踐
本文是www.git tower.com總結的使用git的最佳實踐，其中的大部分實踐具有普適性，可用其他版本控制工具svn，cvs等。原文 best practice of version control in git 每次提交的應該是一系列有關聯的變化。例如，修復了兩個不同的bug應該分別提交兩次...