最近公司產品上線，整個系統架構包含有七八個子系統，并且子系統都是集群部署。所以每次升級維護都要確保盡可能不出問題。因為整個系統剛上線不久，意味著新系統不定期有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下后在操作就行了。

很久沒有寫這么長的文章了，希望對大家有幫助。

?

?

?

?

? ? ?

?

?

?

?

?

?

?

轉載于:https://www.cnblogs.com/sanxiong/p/3802360.html

總結

以上是生活随笔為你收集整理的eclipse svn 分支合并到主干的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。