1. 程式人生 > >svn多分支開發合併技巧(idea or tortoiseSVN)

svn多分支開發合併技巧(idea or tortoiseSVN)

情景和svn多分支合併原理

使用svn好多年了(期間也有使用git),一直對分支和合並敬而遠之,一來是因為沒有特別緊迫的需求,二來即使涉及到分支的管理,也不敢貿然使用合併功能,生怕合併出了問題對團隊造成不良影響,最主要的原因是,自己對分支的目的和合並的方法不甚瞭解,這才是硬傷。

最近涉及電商專案開發和原始碼管理,由於緊急活動需求比較多,又要兼顧新的future的開發,需要經常接觸分支和合並兩項工作。突然發現這玩意整不明白很難開展工作。遂這兩天著重研究了一下,有點收穫,怕以後忘了,故趁著餘溫尚在趕緊寫下來,好記性不如爛筆頭嘛。文章內容主要參考網上的經驗和自已的實踐。TortoiseSVN的幫助文件和Subversion的線上文件,Subversion的線上文件:

http://svnbook.red-bean.com/en/1.5/svn-book.html

先說說什麼是branch。按照Subversion的說法,一個branch是某個development line(通常是主線也即trunk)的一個拷貝,見下圖:
在這裡插入圖片描述

branch存在的意義在於,在不干擾trunk的情況下,和trunk並行開發,待開發結束後合併回trunk中,在branch和trunk各自開發的過程中,他們都可以不斷地提交自己的修改,從而使得每次修改在repository中都有記錄。

設想以下場景,如果你的專案需要開發一個新功能,而該功能可能會修改專案中的絕大多數檔案,而與此同時,你的另一位同事正在進行bug fix,如果你的新功能不在branch中開發而直接在trunk中開發,那麼你極有可能影響另一位同事的bug fix,他/她在bug修復中可能會遇到各種各樣的問題,因為你的頻繁提交程式碼引入了過多的不穩定因素。你可能會說,那我在開發的過程中不提交不就行了,等到我全部開發結束我再提交,是,你可以這麼做,那還要版本控制幹什麼呢?也許等到你最後提交程式碼的時候(也許一週,也許兩週?),你會發現有一大堆conflict等著你resolve。。。

那麼,正確的做法是什麼?使用branch,從trunk建立branch,然後在你的branch上開發,開發完成後再合併到trunk中。

關於branch先講到這裡,下面說說什麼叫做合併。很好理解,當branch開發完成後(包括必要的測試),將branch中的修改同步到trunk中,這個過程有可能包括修改檔案、增加檔案、刪除檔案等等。

說到這裡,貌似本文差不多可以結束了,不就是分支和合並麼?只要再簡單地說說如何建立分支和如何合併就可以收尾了,可能只需兩個命令,也可能只需滑鼠點幾下然後鍵盤敲兩下即可。其實事情遠非這麼簡單,愛動腦筋的同學可能會問了,將branch的改動merge到trunk的時候,和上文說的直接在trunk中全部開發完然後提交有何區別?你最後還不是要處理一大堆conflict?

這個問題問得非常好,其實這正是本文的重點:branch和trunk在並行開發的過程中如何感知對方,branch如何才能在開發過程中不會和trunk越走越遠,導致最後無法合併?試想一下,如果在你開發branch的過程中,trunk中的某個類檔案已經被刪除了(這可能是另外一個傢伙在另一個branch上開發了兩週後才合併到trunk的),而你竟然在這個類檔案上做了大量修改,試問你到最後合併回trunk的時候該有多蛋疼?解決這一問題的唯一手段是,branch要不停地和trunk保持同步,你要及時地知道trunk都做了什麼修改,這些修改是否會影響你正在開發的新功能,如果需要,你必須及時調整branch的程式碼,使之能與trunk“相容”。

那麼如何讓branch和trunk保持同步?合併,從trunk合併到branch,你沒聽錯,是從trunk合併到branch。關於TortoiseSVN的合併,有幾點需要注意:

  1. TortoiseSVN的合併發生在本地,也即你的working copy中,你無需過多擔心會對repository中的程式碼造成影響
  2. 不管是從trunk合併到branch還是最終從branch合併回trunk,在每次合併前最好先update,然後將本地的修改先全部commit,保護好現場,萬一合併不理想隨時都可以revert
  3. 合併完成後看是否能正確編譯,然後測試驗證,最後將合併後的改動提交到repository

環境說明

  • svn(1.8)、tortoiseSVN(svn客戶端)
  • idea
    我們svn程式碼管理是基於分支開發的,不斷合併到主幹,基於主幹測試和打tag釋出。主幹trank上普通開發人員是沒有許可權的,只有研發經理有許可權。所以多分支開發,是基於trank打多個開發分支:如branch_activity,branch_new-future。一般一個開發分支是不是會問題的,每次從開發分支merge到主幹提測,和單分支開發也差不多。當多個分支的時候,分支合併就會出現程式碼覆蓋、衝突等問題。

合併實踐

  • 使用idea 合併分支
    Integrate Project :這種在分支間整合,只能全量merge,不能一個revision,一個revision的處理。兩個分支差異較大時,合併存在覆蓋和丟失程式碼的情況。適合從branch全量合併到trunk上,這塊可以參考下文,使用小烏龜工具合併分支程式碼。
    merge from:
    使用過程,如下截圖說明。可以選擇相對應的revision,部分合並,效果比較好。但是有時候比如,有的分支上有檔案已經刪除,在另一個分支上有修改,這時候可能idea會異常退出svn merge,這個我考慮是idea的bug。這種情況,可以選擇使用tortoiseSVN合併工具,這個svn客戶端應該跟svn的相容性更好。
    在這裡插入圖片描述
    在這裡插入圖片描述
    在這裡插入圖片描述

  • 使用tortoiseSVN工具合併分支
    [參考]https://blog.csdn.net/eggcalm/article/details/6606520
    在/branches/MyProject上右鍵,依次選擇"TortoiseSVN" -> “Merge…”,在彈出的視窗中選擇第一項"Merge a range of revision",這個型別的Merge已經介紹得很清楚,適用於將某個分支或主線上提交的多個revision間的變化合併到另外一個分支上。

在這裡插入圖片描述
點選next後,出現如下視窗:
在這裡插入圖片描述
由於是要從trunk合併到branch,理所當然這裡的"URL to merge from"應該填trunk的路徑,"Revision range to merge"很好理解,就是你要將trunk的哪些revision所對應的變化合併到branch中,可以是某一連串的revision,比如4-7,15-HEAD,也可以是某個單獨的revision號。由於在r4中,trunk修改了Person.java中的talk()方法,所以這裡的revision為選擇的要合併的revision(or revision組)即可。點選next後出現下圖:
在這裡插入圖片描述

在這裡只需保留預設設定即可。在點選Merge按鈕前你可以先Test merge一把,看成功與否,以及merge的詳細資訊。點選Merge按鈕後trunk所做的修改將同步到branch中。
提交合並後的branch:
在這裡插入圖片描述

至此,branch已經完全和trunk同步,branch和trunk的程式碼相處很融洽,沒有任何衝突,如果branch已經開發結束,那是時候將branch合併回trunk了,當然,如果branch還要繼續開發,那你將不斷地重複trunk 2 branch步驟。
將branch合併回trunk:
在/trunk/MyProject上右鍵(注意是在主線的目錄上右鍵),依次選擇"TortoiseSVN" -> “Merge…”,在彈出的視窗中,Merge type選擇第二項"Reintegrate a branch",這種型別的合併適合在分支開發結束後將所有的改動合併回主線。
在這裡插入圖片描述
點選next後出現如下視窗:
在這裡插入圖片描述

在這裡,"From URL"選擇/branches/MyProject,無需選擇revision號,Reintegrate會將branch上所有修改合併到trunk。後面的步驟和上文第9步中的一樣,不再囉嗦了。如無意外,branch將成功合併到trunk,你需要做的只是將合併後的trunk趕緊commit!

總結

  1. 一般分支合併使用idea等IDE就可以了,trunk到branch使用merge revision range,branch合到trunk使用integrate a branch.
  2. 如果實在合併不了,因為ide跟svn可能有相容性問題,終極工具就是tortoiseSVN。
  3. 合併的過程都在本地工作空間,不用擔心svn庫程式碼亂了,本地處理程式碼沒有問題了,再commit到svn對應分支。
    希望對您有幫助,更多分享,歡迎關注本人公眾號:猿來在此。↓↓↓
    微信掃碼: