之前幾節(jié)我們說了Subversion的分支與合并問題，這里我們和大家討論一下Subversion常用分支模式，在這里拿出來和大家分享一下，希望大家有所感悟。

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

大多數(shù)軟件存在這樣一個(gè)生命周期：編碼、測試、發(fā)布，然后重復(fù)。這樣有兩個(gè)問題，***，開發(fā)者需要在質(zhì)量保證小組測試假定穩(wěn)定版本時(shí)繼續(xù)開發(fā)新特性，新工作在軟件測試時(shí)不可以中斷，第二，小組必須一直支持老的發(fā)布版本和軟件；如果一個(gè)bug在***的代碼中發(fā)現(xiàn)，它一定也存在已發(fā)布的版本中，客戶希望立刻得到錯(cuò)誤修正而不必等到新版本發(fā)布。這是版本控制可以做的幫助，典型的過程如下：開發(fā)者提交所有的新特性到主干。每日的修改提交到/trunk：新特性，bug修正和其他。這個(gè)主干被拷貝到“發(fā)布”分支。當(dāng)小組認(rèn)為軟件已經(jīng)做好發(fā)布的準(zhǔn)備（如，版本1.0）然后/trunk會(huì)被拷貝到/branches/1.0。項(xiàng)目組繼續(xù)并行工作，一個(gè)小組開始對(duì)分支進(jìn)行嚴(yán)酷的測試，同時(shí)另一個(gè)小組在/trunk繼續(xù)新的工作（如，準(zhǔn)備2.0），如果一個(gè)bug在任何一個(gè)位置被發(fā)現(xiàn)，錯(cuò)誤修正需要來回運(yùn)送。然而這個(gè)過程有時(shí)候也會(huì)結(jié)束，例如分支已經(jīng)為發(fā)布前的最終測試“停滯”了。

Subversion常用分支模式介紹中，分支已經(jīng)作了標(biāo)簽并且發(fā)布，當(dāng)測試結(jié)束，/branches/1.0作為引用快照已經(jīng)拷貝到/tags/1.0.0，這個(gè)標(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ā)布。整個(gè)過程隨著軟件的成熟不斷重復(fù)：當(dāng)2.0完成，一個(gè)新的2.0分支被創(chuàng)建，測試、打標(biāo)簽和最終發(fā)布，經(jīng)過許多年，版本庫結(jié)束了許多版本發(fā)布，進(jìn)入了“維護(hù)”模式，許多標(biāo)簽代表了最終的發(fā)布版本。

Subversion常用分支模式介紹中，一個(gè)特性分支是本章中那個(gè)重要例子中的分支，你正在那個(gè)分支上工作，而Sally還在/trunk繼續(xù)工作，這是一個(gè)臨時(shí)分支，用來作復(fù)雜的修改而不會(huì)干擾/trunk的穩(wěn)定性，不象發(fā)布分支（也許要永遠(yuǎn)支持），特性分支出生，使用了一段時(shí)間，合并到主干，然后最終被刪除掉，它們在有限的時(shí)間里有用。還有，關(guān)于是否創(chuàng)建特性分支的項(xiàng)目政策也變化廣泛，一些項(xiàng)目永遠(yuǎn)不使用特性分支：大家都可以提交到/trunk，好處是系統(tǒng)的簡單—沒有人需要知道分支和合并，壞處是主干會(huì)經(jīng)常不穩(wěn)定或者不可用，另外一些項(xiàng)目使用分支達(dá)到極限：沒有修改曾經(jīng)直接提交到主干，即使最細(xì)小的修改都要?jiǎng)?chuàng)建短暫的分支，然后小心的審核合并到主干，然后刪除分支，這樣系統(tǒng)保持主干一直穩(wěn)定和可用，但是造成了巨大的負(fù)擔(dān)。

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

最終，有一個(gè)問題就是怎樣保持一個(gè)特性分支“同步”于工作中的主干，在前面提到過，在一個(gè)分支上工作數(shù)周或幾個(gè)月是很有風(fēng)險(xiǎn)的，主干的修改也許會(huì)持續(xù)涌入，因?yàn)檫@一點(diǎn)，兩條線的開發(fā)會(huì)區(qū)別巨大，合并分支回到主干會(huì)成為一個(gè)噩夢。這種情況***通過有規(guī)律的將主干合并到分支來避免，制定這樣一個(gè)政策：每周將上周的修改合并到分支，注意這樣做時(shí)需要小心，需要手工記錄合并的過程，以避免重復(fù)的合并（在在一些時(shí)候，你已經(jīng)準(zhǔn)備好了將“同步的”特性分支合并回到主干，為此，開始做一次將主干***修改和分支的最終合并，這樣以后，除了你的分支修改的部分，***的分支和主干將會(huì)絕對(duì)一致，所以在這個(gè)特別的例子里，你會(huì)通過直接比較分支和主干來進(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ā)線都有了分枝的修改。可以用另一種Subversion常用分支模式考慮這種模式，你每周按時(shí)同步分支到主干，類似于在工作拷貝執(zhí)行svnupdate的命令，最終的合并操作類似于在工作拷貝運(yùn)行svncommit，畢竟，工作拷貝不就是一個(gè)非常淺的分支嗎？只是它一次只可以保存一個(gè)修改。發(fā)布分支特性分支“手工追蹤合并”一節(jié)描述過），你需要小心的撰寫合并的日志信息，精確的描述合并包括的范圍（在“合并一條分支到另一支”一節(jié)中描述過），這看起來像是脅迫，可是實(shí)際上是容易做到的。

 【編輯推薦】

1. Subversion和TortoiseSVN如何在Windows下進(jìn)行構(gòu)建SVN版本控制
2. 剖析來自Linux系統(tǒng)的svn命令
3. 八大特性對(duì)比顯示SVN與CVS的優(yōu)缺點(diǎn)
4. 專家指導(dǎo)：Windows2003下如何進(jìn)行Apache+SVN部署
5. 搭建功能強(qiáng)大Linux SVN控制系統(tǒng)