本節(jié)向大家描述一下常用SVN分支模式，主要內(nèi)容有發(fā)布分支和特殊分支的介紹，歡迎大家一起來學(xué)習(xí)常用SVN分支模式，希望本節(jié)的介紹對大家的學(xué)習(xí)有所幫助。

常用SVN分支模式

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

發(fā)布分支

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

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

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

這個主干被拷貝到“發(fā)布”分支。當(dāng)小組認(rèn)為軟件已經(jīng)做好發(fā)布的準(zhǔn)備（如，版本1.0）然后/trunk會被拷貝到/branches/1.0。

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

分支已經(jīng)作了標(biāo)簽并且發(fā)布，當(dāng)測試結(jié)束，/branches/1.0作為引用快照已經(jīng)拷貝到/tags/1.0.0，這個標(biāo)簽被打包發(fā)布給客戶。

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

整個過程隨著軟件的成熟不斷重復(fù)：當(dāng)2.0完成，一個新的2.0分支被創(chuàng)建，測試、打標(biāo)簽和最終發(fā)布，經(jīng)過許多年，版本庫結(jié)束了許多版本發(fā)布，進(jìn)入了“維護(hù)”模式，許多標(biāo)簽代表了最終的發(fā)布版本。下面我們介紹一下SVN分支模式中的特性分支。

特性分支

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

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

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

最終，有一個問題就是怎樣保持SVN分支模式中一個特性分支“同步”于工作中的主干，在前面提到過，在一個分支上工作數(shù)周或幾個月是很有風(fēng)險的，主干的修改也許會持續(xù)涌入，因?yàn)檫@一點(diǎn)，兩條線的開發(fā)會區(qū)別巨大，合并分支回到主干會成為一個噩夢。

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

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

$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修訂版本的分支，你確定了只在分支上的增量信息，兩條開發(fā)線都有了分枝的修改。

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

【編輯推薦】

1. 實(shí)例剖析TortoiseSvn分支合并
2. SVN分支與合并學(xué)習(xí)大本營
3. 深入講解SVN分支與合并的關(guān)系
4. SVN分支與合并之專家課堂
5. SVN分支維護(hù)專家在線