本節向大家描述一下常用SVN分支模式，主要內容有發布分支和特殊分支的介紹，歡迎大家一起來學習常用SVN分支模式，希望本節的介紹對大家的學習有所幫助。

常用SVN分支模式

版本控制在軟件開發中廣泛使用，這里是團隊里程序員最常用的兩種分支/合并模式的介紹，如果你不是使用Subversion軟件開發，可隨意跳過本小節，如果你是***次使用版本控制的軟件開發者，請更加注意，以下模式被許多老兵當作***實踐，這個過程并不只是針對Subversion，在任何版本控制系統中都一樣，但是在這里使用Subversion術語會感覺更方便一點。

發布分支

首先看一下常用SVN分支模式的發布分支。大多數軟件存在這樣一個生命周期：編碼、測試、發布，然后重復。這樣有兩個問題，***，開發者需要在質量保證小組測試假定穩定版本時繼續開發新特性，新工作在軟件測試時不可以中斷，第二，小組必須一直支持老的發布版本和軟件；如果一個bug在***的代碼中發現，它一定也存在已發布的版本中，客戶希望立刻得到錯誤修正而不必等到新版本發布。

這是版本控制可以做的幫助，典型的過程如下：

開發者提交所有的新特性到主干。每日的修改提交到/trunk：新特性，bug修正和其他。

這個主干被拷貝到“發布”分支。當小組認為軟件已經做好發布的準備（如，版本1.0）然后/trunk會被拷貝到/branches/1.0。

項目組繼續并行工作，一個小組開始對分支進行嚴酷的測試，同時另一個小組在/trunk繼續新的工作（如，準備2.0），如果一個bug在任何一個位置被發現，錯誤修正需要來回運送。然而這個過程有時候也會結束，例如分支已經為發布前的最終測試“停滯”了。

分支已經作了標簽并且發布，當測試結束，/branches/1.0作為引用快照已經拷貝到/tags/1.0.0，這個標簽被打包發布給客戶。

分支多次維護。當繼續在/trunk上為版本2.0工作，bug修正繼續從/trunk運送到/branches/1.0，如果積累了足夠的bug修正，管理部門決定發布1.0.1版本：拷貝/branches/1.0到/tags/1.0.1，標簽被打包發布。

整個過程隨著軟件的成熟不斷重復：當2.0完成，一個新的2.0分支被創建，測試、打標簽和最終發布，經過許多年，版本庫結束了許多版本發布，進入了“維護”模式，許多標簽代表了最終的發布版本。下面我們介紹一下SVN分支模式中的特性分支。

特性分支

一個特性分支是本章中那個重要例子中的分支，你正在那個分支上工作，而Sally還在/trunk繼續工作，這是一個臨時分支，用來作復雜的修改而不會干擾/trunk的穩定性，不象發布分支（也許要永遠支持），特性分支出生，使用了一段時間，合并到主干，然后最終被刪除掉，它們在有限的時間里有用。

還有，關于是否創建特性分支的項目政策也變化廣泛，一些項目永遠不使用特性分支：大家都可以提交到/trunk，好處是系統的簡單—沒有人需要知道分支和合并，壞處是主干會經常不穩定或者不可用，另外一些項目使用分支達到極限：沒有修改曾經直接提交到主干，即使最細小的修改都要創建短暫的分支，然后小心的審核合并到主干，然后刪除分支，這樣系統保持主干一直穩定和可用，但是造成了巨大的負擔。

許多項目采用折中的方式，堅持每次編譯/trunk并進行回歸測試，只有需要多次不穩定提交時才需要一個特性SVN分支，這個規則可以用這樣一個問題檢驗：如果開發者在好幾天里獨立工作，一次提交大量修改（這樣/trunk就不會不穩定。），是否會有太多的修改要來回顧？如果答案是“是”，這些修改應該在特性分支上進行，因為開發者增量的提交修改，你可以容易的回頭檢查。

最終，有一個問題就是怎樣保持SVN分支模式中一個特性分支“同步”于工作中的主干，在前面提到過，在一個分支上工作數周或幾個月是很有風險的，主干的修改也許會持續涌入，因為這一點，兩條線的開發會區別巨大，合并分支回到主干會成為一個噩夢。

這種情況***通過有規律的將主干合并到分支來避免，制定這樣一個政策：每周將上周的修改合并到分支，注意這樣做時需要小心，需要手工記錄合并的過程，以避免重復的合并（在“手工跟蹤合并”一節描述過），你需要小心的撰寫合并的日志信息，精確的描述合并包括的范圍（在“合并分支到另一分支”一節中描述過），這看起來像是脅迫，可是實際上是容易做到的。

在一些時候，你已經準備好了將“同步的”特性分支合并回到主干，為此，開始做一次將主干***修改和分支的最終合并，這樣以后，除了你的分支修改的部分，***的分支和主干將會絕對一致，所以在這個特別的例子里，你會通過直接比較分支和主干來進行合并： 

$cdtrunk-working-copy  
$svnupdate  
Atrevision1910.  
$svnmergehttp://svn.example.com/repos/calc/trunk@1910\  
http://svn.example.com/repos/calc/branches/mybranch@1910  
Ureal.c  
Uinteger.c  
Anewdirectory  
Anewdirectory/newfile…  
 

通過比較HEAD修訂版本的主干和HEAD修訂版本的分支，你確定了只在分支上的增量信息，兩條開發線都有了分枝的修改。

可以用另一種考慮這種模式，你每周按時同步分支到主干，類似于在工作拷貝執行svnupdate的命令，最終的合并操作類似于在工作拷貝運行svncommit，畢竟，工作拷貝不就是一個非常淺的分支嗎？只是它一次只可以保存一個修改。本節講解SVN分支模式完畢。

【編輯推薦】

1. 實例剖析TortoiseSvn分支合并
2. SVN分支與合并學習大本營
3. 深入講解SVN分支與合并的關系
4. SVN分支與合并之專家課堂
5. SVN分支維護專家在線