專家點評Subversion常用分支模式
之前幾節我們說了Subversion的分支與合并問題，這里我們和大家討論一下Subversion常用分支模式，在這里拿出來和大家分享一下，希望大家有所感悟。
版本控制在軟件開發中廣泛使用，這里是團隊里程序員最常用的兩種分支/合并模式的介紹，如果你不是使用Subversion軟件開發，可隨意跳過本小節，如果你是***次使用版本控制的軟件開發者，請更加注意，以下模式被許多老兵當作***實踐，這個過程并不只是針對Subversion，在任何版本控制系統中都一樣，但是在這里使用Subversion術語會感覺更方便一點。
大多數軟件存在這樣一個生命周期：編碼、測試、發布，然后重復。這樣有兩個問題，***，開發者需要在質量保證小組測試假定穩定版本時繼續開發新特性，新工作在軟件測試時不可以中斷，第二，小組必須一直支持老的發布版本和軟件；如果一個bug在***的代碼中發現，它一定也存在已發布的版本中，客戶希望立刻得到錯誤修正而不必等到新版本發布。這是版本控制可以做的幫助，典型的過程如下：開發者提交所有的新特性到主干。每日的修改提交到/trunk：新特性，bug修正和其他。這個主干被拷貝到“發布”分支。當小組認為軟件已經做好發布的準備（如，版本1.0）然后/trunk會被拷貝到/branches/1.0。項目組繼續并行工作，一個小組開始對分支進行嚴酷的測試，同時另一個小組在/trunk繼續新的工作（如，準備2.0），如果一個bug在任何一個位置被發現，錯誤修正需要來回運送。然而這個過程有時候也會結束，例如分支已經為發布前的最終測試“停滯”了。
Subversion常用分支模式介紹中，分支已經作了標簽并且發布，當測試結束，/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分支被創建，測試、打標簽和最終發布，經過許多年，版本庫結束了許多版本發布，進入了“維護”模式，許多標簽代表了最終的發布版本。
Subversion常用分支模式介紹中，一個特性分支是本章中那個重要例子中的分支，你正在那個分支上工作，而Sally還在/trunk繼續工作，這是一個臨時分支，用來作復雜的修改而不會干擾/trunk的穩定性，不象發布分支（也許要永遠支持），特性分支出生，使用了一段時間，合并到主干，然后最終被刪除掉，它們在有限的時間里有用。還有，關于是否創建特性分支的項目政策也變化廣泛，一些項目永遠不使用特性分支：大家都可以提交到/trunk，好處是系統的簡單—沒有人需要知道分支和合并，壞處是主干會經常不穩定或者不可用，另外一些項目使用分支達到極限：沒有修改曾經直接提交到主干，即使最細小的修改都要創建短暫的分支，然后小心的審核合并到主干，然后刪除分支，這樣系統保持主干一直穩定和可用，但是造成了巨大的負擔。
許多項目采用折中的方式，堅持每次編譯/trunk并進行回歸測試，只有需要多次不穩定提交時才需要一個特性分支，這個規則可以用這樣一個問題檢驗：如果開發者在好幾天里獨立工作，一次提交大量修改（這樣/trunk就不會不穩定。），是否會有太多的修改要來回顧？如果答案是“是”，這些修改應該在特性分支上進行，因為開發者增量的提交修改，你可以容易的回頭檢查。
最終，有一個問題就是怎樣保持一個特性分支“同步”于工作中的主干，在前面提到過，在一個分支上工作數周或幾個月是很有風險的，主干的修改也許會持續涌入，因為這一點，兩條線的開發會區別巨大，合并分支回到主干會成為一個噩夢。這種情況***通過有規律的將主干合并到分支來避免，制定這樣一個政策：每周將上周的修改合并到分支，注意這樣做時需要小心，需要手工記錄合并的過程，以避免重復的合并（在在一些時候，你已經準備好了將“同步的”特性分支合并回到主干，為此，開始做一次將主干***修改和分支的最終合并，這樣以后，除了你的分支修改的部分，***的分支和主干將會絕對一致，所以在這個特別的例子里，你會通過直接比較分支和主干來進行合并：
- $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修訂版本的分支，你確定了只在分支上的增量信息，兩條開發線都有了分枝的修改。可以用另一種Subversion常用分支模式考慮這種模式，你每周按時同步分支到主干，類似于在工作拷貝執行svnupdate的命令，最終的合并操作類似于在工作拷貝運行svncommit，畢竟，工作拷貝不就是一個非常淺的分支嗎？只是它一次只可以保存一個修改。發布分支特性分支“手工追蹤合并”一節描述過），你需要小心的撰寫合并的日志信息，精確的描述合并包括的范圍（在“合并一條分支到另一支”一節中描述過），這看起來像是脅迫，可是實際上是容易做到的。
【編輯推薦】
