SVN分支管理策略個人見解

使用svn做為原始碼管理工具已有幾年，但一直都只是使用到了t

runk。最近專案中發版本每次都會將

乙個版本的檔案

拷貝打包為rar壓縮檔案，下個版本迭代則重新在svn服務端建立新的repository用於管理。顯然這tag版本脫離了svn的管理，日誌記錄也會發生斷層。

於是最近就查閱了一些文章，結合實際對 trunk、tags、branches 進行體驗操作，有點收穫，怕以後忘了，故做此記錄。

其中trunk：主開發分支，所有最新的**都在這裡。

tags：乙個里程碑版本，一般都可保證直接上線(名字：」v1.0」,」v1.1」,」v2.1」,」school_v1.0」,」school_v1.1」…)，用於存放發布的版本。

hotfix branch：修正bug的分支(名字：」hotfix_v1.x」,」 school_

hotfix_v1.x」, 「school_

hotfix_v1.x」)，從需要修復的tag拉出分支，用於解決已上線版本的bug。

customize branch：定製化需求的開發分支(名字：」school_develop」…)，用於定製化需求開發乙個版本。

visualsvn server的安裝使用網上有很多文章，此處不做描述。

首先checkout在服務端repository建立的test，

預設建立了三個空資料夾。

提交迭代版本更新。

基於trunk中最新版本建立tag_v1.0。在/trunk/myproject目錄上右鍵，依次選擇"tortoisesvn" -> "branch/tag..."，在彈出視窗的"to path"中填入tag的位址。

提交後在資料夾更新後會在test\tags資料夾下出現mypro_v1.0資料夾，tags目錄下的mypro_v1.0資料夾就是以trunk中指定的版本拷貝的副本做為版本v1.0進行的封存。

當版本v1.0發布上線後，出現線上bug後需要修復，則以tag中mypro_v1.0建立hotfix branch(步驟和建立tag類似)，在hotfix的分支中修復問題。修復完成後需要將此次的改動marge(合併)到trunk中同時創tag_v1.1進行發布。

提交後在資料夾更新後會在test\branches資料夾下出現bugfix_by_account資料夾，在此基礎上修復問題並提交。

在/branches/bugfix_by_account目錄上右鍵，依次選擇"tortoisesvn" ->"revision graph"，在彈出的視窗中可以看到版本分支圖。

在/trunk/myproject目錄上右鍵，依次選擇"tortoisesvn" ->"merge..."，

點next出現如下視窗，

如果trunk中的版本修改過的檔案與hotfix分支中的修改不重合則不會產生衝突。下圖是trunk進行過版本提交，與hotfix分支中的修改產生衝突。

點選 edit confict解決衝突。

衝突處理完後點選resolved，衝突解決完成本地trunk中已包含hotfix分支的內容，合併後需要提交至svn伺服器。

hotfix分支修復完成後建立tag_v1.1與之前trunk建立tag_v1.0類似。

完成以上動作後的版本分支圖如下。

定製化分支使用的方式和之前建立branch方式類似，在此不做贅述。

合併發生在本地working copy，只要你不提交就不會影響到repository。

合併前一定要先update、commit，保證不會out of day，並將本地的修改儲存到repository。

使用svn建立的分支都會在指定的資料夾中建立副本，如果是在不同的分支資料夾中開發時候需要重新對專案配置（eg：iis外部主機），也可在trunk中切換分支則不用修改配置，但是svn服務端需要保持可連線狀態。

最後說一句用過git之後，再也不想用其它[源**]管理器。