一、使用svn遇到的問題

從參加工作至今，一直使用svn作為代碼版本工具，基本能夠滿足日常工程開發過程中的代碼版本管理需求，直到維護目前的線上運行的項目。

場景一：

完成一個版本的開發后，例如3.0版，在svn上標記一下當前版本，團隊繼續開發版本4.0。過幾天后發現線上的bug1，這時候從哪個版本的代碼修復bug1，有兩種選擇，一種是直接在4.0的開發代碼上改，盡量把代碼還原到3.0時的狀態，再修改bug1；另一種選擇是從svn標記的版本檢出進行修改。這兩種方法都嘗試過，但問題是過幾天再出現bug2，沒有地方能找到3.0版+bug1修復的代碼，bug2修復遇到困難。

場景二：

隨著平臺3.0版本的發布，需要長時間開發大版本的需求減少，零碎的小需求增多。如果把小需求都拖到大版本一起上線，會對平臺運營產生影響。因此，小版本迭代和大版本開發的同時進行，將成為未來一段時間團隊的矛盾點。而與此同時，如何能管理兩個并行版本的代碼，對svn來講幾乎無解。

二、嘗試更換git

通過在網上的簡單了解，git版本庫擁有分支管理的功能，似乎可以解決svn使用過程中的問題，決定在團隊內部進行小規模的嘗試。

經過配置管理同事的努力，在公司內網搭建了gitlab服務，開始git之旅。

首先在iOS和安卓開發團隊進行了試點，初步確定了以人為單位打分支，每人每天下午下班前提交代碼到自己的分支，全部提交后由團隊負責人把代碼合并到master分支。

這種方式進行了一個版本的開發，也沒出什么亂子，仿佛git就是一個復雜版的svn，直到把git推廣到后臺開發團隊。

三、問題出現

當后臺也開始使用git后，開始出現奇怪的問題，當多人的開發的分支合并到master時，開始出現代碼混亂，偶爾操作不規范時還會引起代碼的丟失。

另外，由于后臺開發成員要多于客戶端的開發成員數，每天的代碼分支合并，會成為后臺負責人的一項工作負擔。

之所以在后臺團隊開始使用git后出現這些問題，主要原因還是客戶端開發人數少，每個端（工程）兩個人維護，以人為單位打分支的弊端并沒有被發現。

四、新思路

出現問題后開始尋找解決辦法，在網上看到一個說法，引起了我的思考：master分支保持和線上版本一致。

那么，是不是可以嘗試多人共用一個遠程分支？模擬了一下在兩臺開發機器上使用同一個遠程分支的各種情況，事實證明可行。

多人共用一個遠程分支時，和使用svn的效果是相似的（不相同，這里不展開說）。

既然多人可以共同使用一個遠程分支，是不是可以以版本為單位打遠程分支？

五、解決方案

以平臺實際的版本開發，推演了一下新思路，平臺要在三個月后上線4.0版本，那么打一個4.0dev分支。

三個月期間需要上線三個小版本，分別是3.1、3.2、3.3，由于三個小版本按順序開發，所以只使用一個遠程分支即可。

這時候一共有三個分支master、4.0dev、3.1dev，需要開發對應版本的同事，克隆對應版本的分支即可。

當3.1版本開發完成，經過測試上線后，首先將3.1dev的分支合并到master分支，這樣就保持了master分支和線上代碼一致。合并后，4.0dev分支從master 拉取代碼，拉取成功后（有沖突，解決過程不展開說），4.0dev分支就實際包含了3.1已發布的代碼和4.0正在開發的代碼，完美實現了版本的過度。

六、小驚喜

無意間發現sourcetree的一個功能，分支切換?？梢园驯镜毓ぷ鞲北娟P聯到多個遠程分支，需要時雙擊切換到對應的分支，并刷新一下開發環境即可。

這讓一個人參與多個分支的開發，變得十分便捷。

七、線上問題修改

解決了版本分支的問題，解決線上問題也變的很輕松。打出一個bug修復分支，在分支上修改代碼，經過測試后代碼發布到線上環境。發布成功后合并bug修復分支到master分支，合并后各個開發分支再從master把代碼拉取到本分支。

寫在最后

經過兩個版本的摸索，整個團隊完成了從svn到git版本庫的過度。過程中經歷過不少困難，遇到過很多的阻力，冒著代碼丟失和進度無法推進的風險，最終還是成功的完成了這一步。

快速版本迭代成為可能。