SVN 主幹(trunk)、分支(branch )、標記(tag)

主幹(trunk)、分支(branch )、標記(tag)

在SVN中Branch/tag在一個功能選項中，在使用中也每每產生混淆。

 
在實現上，branch和tag，對於svn都是使用copy實現的，因此他們在默認的權限上和通常的目錄沒有區別。至於什麼時候用tag，什麼時候用branch，徹底由人主觀的根據規範和須要來選擇，而不是強制的（好比cvs）。

通常狀況下，

trunk：是用來作主方向開發的，一個新模塊的開發，這個時候就放在trunk，當模塊開發完成後，須要修改，就用branch。 
branch：是用來作並行開發的，這裏的並行是指和trunk進行比較。
tag：是用來作一個milestone的，不論是不是發佈版本，但都是一個可用的版本。這裏，應該是隻讀的。更多的是一個顯示用的，給人一個可讀的標記。

好比，3.0開發完成，這個時候要作一個tag，tag_release_3_0，而後基於這個tag作發佈，好比安裝程序等。trunk進入 3.1的開發，可是3.0發現了bug，那麼就須要基於tag_release_3_0作一個分支(branch)，branch_bugfix_3_0，基於這 個branch進行bug修改，等到bugfix結束，作一個tag，tag_release_3_0_1，而後，根據須要決定 branch_bugfix_3_0是否併入主幹(trunk)。

對於svn還要注意的一點，就是它是全局版本號，其實這個就是一個tag的標記，因此咱們常常能夠看到，什麼什麼release，基於xxx項目的 2xxxx版本。就是這個意思了。可是，它還明確的給出一個tag的概念，就是由於這個更加的可讀，畢竟記住tag_release_1_0要比記住一個 很大的版本號容易的多。

branches：分枝
當多我的合做，可能有這樣的狀況出現：John忽然有個想法，跟原先的設計不太一致，多是功能的添加或者日誌格式的改進等等，總而言之，這個想法可能需 要花一段時間來完成，而這個過程當中，John的一些操做可能會影響Sally的工做，John從現有的狀態單獨出一個project的話，又不能及時獲得 Sally對已有代碼作的修正，並且獨立出來的話，John的嘗試成功時，跟原來的合併也存在困難。這時最好的實踐方法是使用branches。 John創建一個本身的branch，而後在裏面實驗，必要的時候從Sally的trunk裏取得更新，或者將本身的階段成果聚集到trunk中。
建立分支的命令：

（svn copy SourceURL/trunk DestinationURL/branchName -m "Creating a private branch of xxxx/trunk." ）

trunk：主幹
主幹，通常來講就是開發的主要呆的地方，


tag:：標記
在通過了一段時間的開發後，項目到達了一個里程碑階段，你可能想記錄這一階段的代碼的狀態，那麼你就須要給代碼打上標籤。
建立標記的命令：
(svn cp file:///svnroot/mojavescripts/trunk file:///svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1-m "taged mirrorutils_rel_0_0_1")

另有一說，無所謂誰對誰錯。

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

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

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

在這須要說明下分三個目錄的緣由，若是項目分爲一期、二期、三期等，那麼一期上線時的穩定版本就應該在一期完成時將代碼copy到branches上，這樣二期開發的代碼就對一期的代碼沒有影響，如新增的模塊就不會部署到生產環境上。而branches上的穩定的版本就是發佈到生產環境上的代碼，若是用戶使用的過程當中發現有bug，則只要在branches上修改該bug，修改完bug後再編譯branches上最新的代碼發佈到生產環境便可。

 

 

 

tags的做用是將在branches上修改的bug的代碼合併到trunk上時建立個版本標識，之後branches上修改的bug代碼再合併到trunk上時就從tags的version到branches最新的version合併到trunk，以保證前期修改的bug代碼不會再合併。

-------------------------------------------------------------------------------------------

一直以來用svn只是看成cvs，也歷來沒有仔細看過文檔，直到今天用到，纔去翻看svn book文檔，慚愧

需求一：
有一個客戶想對產品作定製，可是咱們並不想修改原有的svn中trunk的代碼。
方法：
用svn創建一個新的branches，從這個branche作爲一個新的起點來開發
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"

Tip:

若是你的svn中之前沒有branches這個的目錄，只有trunk這個，你能夠用
svn mkdir branches
新建個目錄

需求二：
產品開發已經基本完成，而且經過很嚴格的測試，這時候咱們就想發佈給客戶使用，發佈咱們的1.0版本
svn copy svn://server/trunk svn://server/tags/release-1.0 -m "1.0 released"

咦，這個和branches有什麼區別，好像啥區別也沒有？
是的，branches和tags是同樣的，都是目錄，只是咱們不會對這個release-1.0的tag作修改了，再也不提交了，若是提交那麼就是branches

需求三：
有一天，忽然在trunk下的core中發現一個致命的bug,那麼全部的branches必定也同樣了，該怎麼辦？
svn -r 148:149 merge svn://server/trunk branches/ep

 

 

 

 

 

來源：SVN標記 trunk tag branch - - ITeye技術網站 http://sd4886656.iteye.com/blog/1174892