svn代碼版本管理總結

svn代碼版本管理

1.0開發，作dev1.0的branch
此時的目錄結構
svn://proj/
             +trunk/ (不負擔開發任務)
             +branches/
                           +dev_1.0 (copy from trunk)
             +tags/ 
1.0開發完成，merge dev1.0到trunk
此時的目錄結構
svn://proj/
             +trunk/ (merge from branch dev_1.0) ===>測試，打tag或者修改合併後的bug，擔負bug代碼修改
             +branches/
                           +dev_1.0 (開發任務結束，freeze)
             +tags/ 
1) 合併後，測試若是有bug，能夠直接在trunk上修改bug，直到修正後打tag進行發佈
2）合併後，測試無問題直接打tag發佈
發佈後發現存在bug：須要修改，基於1.0的tag作branch_buffix_1.0
此時的目錄結構
svn://proj/
             +trunk/ 
             +branches/
                           +dev_1.0 (開發任務結束，freeze)
                           +dev_2.0 （進行2.0開發）
               +branch_buffix_1.0
             +tags/
                     +tag_release_1.0 (copy from trunk) 
    1）若是2.0開發開始，但並沒合併入主幹：branch_buffix_1.0中修正bug後合併到主幹，經過主幹打tag發佈
    2）若是2.0開發結束，並且合併入主幹：branch_buffix_1.0中修正bug後依然合併到主幹，但經過分支branch_buffix_1.0打tag發佈
依次類推！！

總結：
1）tag上不作任務代碼修改
2）新需求開發，從主幹（最新穩定的）作分支在分支上開發
3）新需求分支開發完成或者分支bug修正後，都必須合併到主幹
4）主幹可在合併後發現問題（並沒打tag）作部分修改

這是方法之一，比較適用於那些常常改動，bug較多的網站開發。

如下是收集出來的各方法說明：

SVN中Branch和tag創建的方法比較簡單，totoiseSVN中的操做是:
1.選擇Branch和tag..
2.在出來的界面中的ToURL中填上URL，通常是svn://IP/Project/branches/branch-1,這樣就創建了一個 branch-1的branch.創建tag是同樣的操做，只不過URL通常是svn://IP/Project/tags/tag-1
3.後面的Createcopyfrom是用於選擇從你當前的workingbase中的哪一個版本中創建Branch和tag，能夠根據本身的選擇來訂 制，通常選擇HeadRevision

建分支
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"

>svn trunk，branch，tag
1. branch和tag，對於svn都是使用copy實現的，因此他們在默認的權限上和通常的目錄沒有區別
3. 介紹一下
trunk：表示開發時版本存放的目錄，即在開發階段的代碼都提交到該目錄上。
branches：表示發佈的版本存放的目錄，即項目上線時發佈的穩定版本存放在該目錄中。
tags：表示標籤存放的目錄。
3.通常狀況下，
tag，是用來作一個milestone的，不論是不是release，都是一個可用的版本。這裏，應該是隻讀的。更多的是一個顯示用的，給人一個可讀（readable）的標記。
branch，是用來作並行開發的，這裏的並行是指和trunk進行比較。 
好比，3.0開發完成，這個時候要作一個tag，tag_release_3_0，而後基於這個tag作release，好比安裝程序等。trunk進入 3.1的開發，可是3.0發現了bug，那麼就須要基於tag_release_3_0作一個branch，branch_bugfix_3_0，基於這個branch進行bugfix，等到bugfix結束，作一個tag，tag_release_3_0_1，而後，根據須要決定 branch_bugfix_3_0是否併入trunk。 

trunk ：表示開發時版本存放的目錄，即在開發階段的代碼都提交到該目錄上。

branches ：表示發佈的版本存放的目錄，即項目上線時發佈的穩定版本存放在該目錄中。

tags ：表示標籤存放的目錄。 

轉載  SVN的trunk branch tag 收藏

Subversion有一個很標準的目錄結構，是這樣的。
好比項目是proj，svn地址爲svn://proj/，那麼標準的svn佈局是

svn://proj/|+-trunk+-branches+-tags
這是一個標準的佈局，trunk爲主開發目錄，branches爲分支開發目錄，tags爲tag存檔目錄（不容許修改）。可是具體這幾個目錄應該如何使用，svn並無明確的規範，更多的仍是用戶本身的習慣。

對於這幾個開發目錄，通常的使用方法有兩種。我更多的是從軟件產品的角度出發（好比freebsd），由於互聯網的開發模式是徹底不同的。
第一種方法，使用trunk做爲主要的開發目錄。
通常的，咱們的全部的開發都是基於trunk進行開發，當一個版本/release開發告一段落（開發、測試、文檔、製做安裝程序、打包等）結束後，代碼處於凍結狀態（人爲規定，能夠經過hook來進行管理）。此時應該基於當前凍結的代碼庫，打tag。當下一個版本/階段的開發任務開始，繼續在trunk進行開發。
此時，若是發現了上一個已發行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在開發的版本（Developing Version）沒法知足時間要求，這時候就須要在上一個版本上進行修改了。應該基於發行版對應的tag，作相應的分支（branch）進行開發。
例如，剛剛發佈1.0，正在開發2.0，此時要在1.0的基礎上進行bug修正。
按照時間的順序

1.0開發完畢，代碼凍結 
基於已經凍結的trunk，爲release1.0打tag
此時的目錄結構爲
svn://proj/
             +trunk/ (freeze)
             +branches/
             +tags/
                     +tag_release_1.0　(copy from trunk) 
2.0開始開發，trunk此時爲2.0的開發版 
發現1.0有bug，須要修改，基於1.0的tag作branch
此時的目錄結構爲
svn://proj/
             +trunk/ ( dev 2.0 )
             +branches/
                           +dev_1.0_bugfix (copy from tag/release_1.0)
             +tags/
                     +release_1.0　(copy from trunk) 
在1.0 bugfix branch進行1.0 bugfix開發，在trunk進行2.0開發 
在1.0 bugfix 完成以後，基於dev_1.0_bugfix的branch作release等 
根據須要選擇性的把dev_1.0_bugfix這個分支merge回trunk（何時進行這步操做，要根據具體狀況） 
這是一種很標準的開發模式，不少的公司都是採用這種模式進行開發的。trunk永遠是開發的主要目錄。

第二種方法，在每個release的branch中進行各自的開發，trunk只作發佈使用。
這種開發模式當中，trunk是不承擔具體開發任務的，一個版本/階段的開發任務在開始的時候，根據已經release的版本作新的開發分支，而且基於這個分支進行開發。仍是舉上面的例子，這裏面的時序關係是。

1.0開發，作dev1.0的branch
此時的目錄結構
svn://proj/
             +trunk/ (不擔負開發任務 )
             +branches/
                           +dev_1.0 (copy from trunk)
             +tags/ 
1.0開發完成，merge dev1.0到trunk
此時的目錄結構
svn://proj/
             +trunk/ (merge from branch dev_1.0)
             +branches/
                           +dev_1.0 (開發任務結束，freeze)
             +tags/ 
根據trunk作1.0的tag
此時的目錄結構
svn://proj/
             +trunk/ (merge from branch dev_1.0)
             +branches/
                           +dev_1.0 (開發任務結束，freeze)
             +tags/
                     +tag_release_1.0 (copy from trunk) 
1.0開發，作dev2.0分支
此時的目錄結構
svn://proj/
             +trunk/ 
             +branches/
                           +dev_1.0 (開發任務結束，freeze)
                           +dev_2.0 （進行2.0開發）
             +tags/
                     +tag_release_1.0 (copy from trunk) 
1.0有bug，直接在dev1.0的分支上修復



詳細說明我是如何應用SVN trunk(樹幹)、branches(分支)和tags(標記)。這種方法一樣被稱爲「branch always」，二者很是接近。可能我所介紹的並非最好的方法，可是它會給新手一些解釋說明，告訴他們trunk、branches和tags是什麼， 而且該如何去應用它們。

　　固然，若是本文有些要點須要澄清/確認，亦或者有一些錯誤的觀點，還請你評論，自由發表本身的觀點。

——簡單的對比

　　SVN的工做機制在某種程度上就像一顆正在生長的樹：

    * 一顆有樹幹和許多分支的樹
    * 分支從樹幹生長出來，而且細的分支從相對較粗的樹幹中長出
    * 一棵樹能夠只有樹幹沒有分支（可是這種狀況不會持續好久，隨着樹的成長，確定會有分支啦，^^）
    * 一顆沒有樹幹可是有不少分支的樹看起來更像是地板上的一捆樹枝
    * 若是樹幹患病了，最終分支也會受到影響，而後整棵樹就會死亡
    * 若是分支患病了，你能夠剪掉它，而後其餘分支還會生長出來的哦！
    * 若是分支生長太快了，對於樹幹它可能會很是沉重，最後整棵樹會垮塌掉
    * 當你感受你的樹、樹幹或者是分支看起來很漂亮的時候，你能夠給它照張相，這樣就就能夠記得它在那時是多麼的贊。

——Trunk

　　Trunk是放置穩定代碼的主要環境，就好像一個汽車工廠，負責將成品的汽車零件組裝在一塊兒。

　　如下內容將告訴你如何使用SVN trunk：

    *
      除非你必須處理一些容易且能迅速解決的BUG，或者你必須添加一些無關邏輯的文件（好比媒體文件：圖像，視頻，CSS等等），不然永遠 不要在trunk直接作開發
    *
      不要由於特殊的需求而去對先前的版本作太大的改變，如何相關的狀況都意味着須要創建一個branch（以下所述）
    *
      不要提交一些可能破壞trunk的內容，例如從branch合併
    *
      若是你在某些時候偶然間破壞了trunk，bring some cake the next day (」with great responsibilities come… huge cakes」)

——Branches

　　一個branch就是從一個SVN倉庫中的子樹所做的一份普通拷貝。一般狀況它的工做相似與UNIX系統上的符號連接，可是你一旦在一個SVN branch裏修改了一些文件，而且這些被修改的文件從拷貝過來的源文件獨立發展，就不能這麼認爲了。當一個branch完成了，而且認爲它足夠穩定的時 候，它必須合併回它原來的拷貝的地方，也就是說：若是原來是從trunk中拷貝的，就應該回到trunk去，或者合併回它原來拷貝的父級branch。

　　如下內容將告訴你如何使用SVN branches：

    *
      若是你須要修改你的應用程序，或者爲它開發一個新的特性，請從trunk中建立一個新的branch，而後基於這個新的分支進行開發
    *
      除非是由於必須從一個branch中建立一個新的子branch，不然新的branch必須從trunk建立
    *
      當你建立了一個新branch，你應當當即切換過去。若是你沒有這麼作，那你爲何要在最初的地方建立這個分支呢？

——Tags

　　從表面上看，SVN branches和SVN tags沒有什麼差異，可是從概念上來講，它們有許多差異。其實一個SVN tags就是上文所述的「爲這棵樹照張相」：一個trunk或者一個branch修訂版的命名快照。

　　如下內容將告訴你如何使用SVN tags：

    *
      做爲一個開發者，永遠不要切換至、取出，或者向一個SVN tag提交任何內容：一個tag比如某種「照片」，並非實實在在的東西，tags只可讀，不可寫。
    *
      在特殊或者須要特別注意的環境中，如：生產環境（production）、？（staging）、測試環境（testing）等等，只 能從一個修復過的（fixed）tag中checkout和update，永遠不要commit至一個tag。
    *
      對於上述說起到的環境，能夠建立以下的tags：「production」，「staging」，「testing」等等。你也能夠根 據軟件版本、項目的成熟程度來命名tag：「1.0.3」，「stable」，「latest」等等。
    *
      當trunk已經穩定，而且能夠對外發布，也要相應地從新建立tags，而後再更新相關的環境（production, staging, etc）

——工做流樣例

　　假設你必須添加了一個特性至一個項目，且這個項目是受版本控制的，你差很少須要完成以下幾個步驟：

   1.
      使用SVN checkout或者SVN switch從這個項目的trunk得到一個新的工做拷貝（branch）
   2.
      使用SVN切換至新的branch
   3.
      完成新特性的開發（固然，要作足夠的測試，包括在開始編碼前）
   4.
      一旦這個特性完成而且穩定（已提交），並通過你的同事們確認，切換至trunk
   5.
      合併你的分支至你的工做拷貝（trunk），而且解決一系列的衝突
   6.
      從新檢查合併後的代碼
   7.
      若是可能的話，麻煩你的同事對你所編寫、更改的代碼進行一次複查（review）
   8.
      提交合並後的工做拷貝至trunk
   9.
      若是某些部署須要特殊的環境（生成環境等等），請更新相關的tag至你剛剛提交到trunk的修訂版本
  10.
      使用SVN update部署至相關環境

 

轉自：http://blog.csdn.net/xiaomu_fireant/article/details/6195622