SVN 多分支管理

前言

    實際開發過程當中，會遇到多需求開發的同事維護線上版本bug。主版代碼要一直和生產環境的程序保持一致，若是是小bug解決後提交部署沒有問題，可是若是是比較難修復的bug，中間不能夠在主版上提交，須要在分支上開發，測試經過後再提交主版。如何在修改bug過程當中在各個分支同步，今天作了一些研究，能夠知足使用須要。

建立分支

建立一個開發新需求的分支，一個修改bug的分支。

開發過程

修改bug分支  

  在修改bug分支提交代碼。

開發分支

開發分支同步修復的bug

 第一個選項：合併指定的版本，能夠是從分支合併到主幹，也能夠是主幹合併的版本，主要做用把分支的部份修改合併到主幹上。

第二個選項：復興分支，這裏會把分支上全部的需改都合併到主幹上。若是隻想合併修改的一部分，並適合這項。

第三個選項：將主幹上的修改合併到分支。

第四個選項：2個不一樣的分支合併，但其實也能夠是分支和主幹的合併，只要from選擇爲主幹就行。

我通常使用第一個選項。點擊next後常常後提示兩個錯誤。

第二個錯誤，查看資源歷史記錄，能夠看到星標在4204，點擊update後星標就會移動到4207。就能夠繼續合併了，具體原理如今還不知道。

選中在修改bug分支上的提交

合併結束後有衝突解決衝突，沒有衝突能夠將修改內容提交到當前分支

後記-中間遇到的疑問

    合併後和資源庫對比，除了修改的java文件，老是有文件夾也提示和資源庫有不一樣的地方。

    通過查看同步過來的文件夾的文件屬性發生變化，比較文件夾的SVN properties.

經過比較能夠看到文件屬性中多了一個4206的版本號，4206是修改分支提交時的版本號。

若是隻提交修改的java文件，版本顯示頁面不會顯示4206

若是連文件夾提交回提示在版本顯示頁面多了4206，可是我點擊提交的時候提示了out of date 錯誤。我就有資源庫的內容覆蓋更新了沒有再繼續操做。

將修改的bug同步到主版的過程也相似。