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

在實現上，branch和tag，對于svn都是使用copy實現的，所以他們在默認的權限上和一般的目錄沒有區別。至于何時用tag，何時用branch，完全由人主觀的根據規范和需要來選擇，而不是強制的（比如cvs）。

一般情況下，
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。

對于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代碼不會再合并。

轉自：

http://hi.baidu.com/stevenchan/blog/item/bb70c1951b576d4dd1135e3a.html

http://hi.baidu.com/cc0cc/blog/item/f68cb0581e86add99d82043d.html