最近公司產品上線，整個系統架構包含有七八個子系統，並且子系統都是集群部署。所以每次升級維護都要確保盡可能不出問題。因為整個系統剛上線不久，意味着新系統不定期有BUG需修復，但新功能模塊也在持續的開發中(可能持續的時間還不短)，所以就引發一個問題：持續開發的新功能代碼與生產上的代碼 如何進行隔離開來進行維護，而且二者還需要不定期的合並代碼。所以就研究了下SVN分支。
首先需厘清SVN的分支以下幾個概念：
trunk: 主干(可以理解為開發環境的代碼，平常做開發的工作目錄)
branches：從主干拷貝了一份代碼重新在svn服務器上的建了個分支目錄(通常叫branch，一般與生產上的代碼保持同步)
tag:主干版本標記（標識每次大的升級版本號）。
我們項目目前的版本管理策略如下（可以根據自已的項目實際需要建立不同的版本管理策略）：
1、系統在沒有上線之前，只有一個主干(trunk)，所有開發人員在主干上進行協同開發。
2、系統上線之后，在主干的基礎上創建一個分支，該分支上主要用於修復生產環境的BUG，或者緊急新功能上線。主干仍然進行新功能模塊的開發。
3、每次生產環境的升級，都從分支上進行打包部署。升級完之后需將分支上改動的代碼及時合並到主干上(開發人員常常忘記,切記)。
4、新功能在主干上開發好了，需要進行一次大的升級，可以先將主干打上一個TAG做為大版本號，並且同時在此基礎上創建一個對應的分支，然后切換到分支上進行打包部署，這個版本的生產代碼維護也在分支上。
原則：分支用於生產代碼維護，主干用於平時開發，TAG用於主干大版本的標記。
由於我們項目由好幾個子系統構成一個大的集群系統，系統之間的版本統一就顯得很重要。所以每次上線，即使相關子系統沒有代碼改動，也需要重新建立一個分支版本以適應其它子系統的版本改動。
說了這么多之后，來說下具體分支合並到主干上的操作，因為這部分最容易出錯：
合並根據目標不同分為2種：
1、分支合並到主干：主要用在修復完生產BUG，並上線之后。需把改動的代碼合並到主干上。
2、主干合並到分支：公用的邏輯改動，需反映到所有並行的分支上。
注意：合並是要在目標目錄上進行操作的，如：分支合並到主干(主干為目標)，需切換到主干上操作合並功能，主干合並到分支(分支為目標)，需切換到分支上進行操作。
分支合並到主干的具體步驟:
1、主干目錄右鍵選擇合並
出現以上6個合並選項，
第一個選項：合並指定的版本，可以是從分支合並到主干，也可以是主干合並的版本，主要作用把分支的部份修改合並到主干上。
第二個選項：復興分支，這里會把分支上所有的需改都合並到主干上。如果只想合並修改的一部分，並適合這項。
第三個選項：將主干上的修改合並到分支。
第四個選項：2個不同的分支合並，但其實也可以是分支和主干的合並，只要from選擇為主干就行。
通常選擇第一項或第四項進行操作，這里需要注意的是：
這里其實就是比對TO版本和FROM版本的差異，並把差異合並到TO的當前版本(head版本)中去。
注：如果要把分支所有的修改合並到主干上，FROM需要選擇主干創建見分支時的版本號，TO選擇分支最新版本（head版本）就行了。
如果FROM也選擇主干head版本，TO也選擇head版本，就會把所有分支與主干不同的差異覆蓋到當前主干上來。造成主干的文件被分支覆蓋。
合並當中出現：
no uncommited modified :表示當前版本還有沒有提交的文件，如果不需要提交就選擇revert.
working copy at a single version：表示當前目錄沒有從SVN服務器更新最新的版本。update下后在操作就行了。
很久沒有寫這么長的文章了，希望對大家有幫助。