我們專案目前的版本管理策略如下（可以根據自已的專案實際需要建立不同的版本管理策略）：
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下後在操作就行了。
如果有衝突可以不提交有衝突檔案。提交沒有衝突的檔案完成之後在本地修改衝突的檔案，修改完成之後再提交修改的衝突檔案。
svn主幹開闢分支 分支合併到主幹
從主幹拉出分支 1，右鍵本地svn主幹專案，先從主幹拉去乙個分支 2，指定分支在svn上的路徑 3，此時可以將分支checkout到本地，在分支上進行新版本的開發 把分支合併到主幹 1，當新功能開發測試完畢後，需要將分支合併到主幹。右鍵本地svn主幹專案，選擇 合併 2，選擇要進行的操作 合併節點到...
SVN分支合併到主幹
使用工具tortoisesvn。前提 1 主幹 是線上的穩定 2 分支有改動，主幹合併分支 3 分支改動的 已經提交 一 我們來到分支 目錄，右鍵，選擇show log 檢視提交日誌 選擇最近新提交的記錄 也就是你想要合併到主幹上的內容 右鍵 之後會讓你選擇你本地的主幹目錄檔案位址，我這裡是trun...
SVN 合併的思考 SVN 分支合併主幹
今天在使用 svn 的過程中遇到了這麼乙個問題 我們在乙個月前從主幹上拉出了乙個分支，乙個月的開發過去了，發現不論是分支還是主幹上都進行了非常繁雜的修改，此時我們的測試要求先把主幹上的 合併到分支上進行測試，那麼現在問題來了，如何將主幹上的 合併到分支上呢？有關 svn 的合併的問題，其實都可以在這...