三者定義

trunk:團隊中大部分成員工作的主要倉庫，前期大的團隊的程式碼管理的主要控制元件，它的功能的側重點是開發階段的程式碼的管理的和整合，由於svn的衝突解決方式來進行程式碼衝突的處理，一般是最後提交的需要進行程式碼的處理，Xcode5以後的版本加強了對於svn的整合，所以現在Xcode可以更加方便的進行程式碼的提交和衝突解決，但是為了更好的進行分支和程式碼更新歷史的管理，最好使用客戶端進行輔助管理，比較推薦的Versions比較方便，不需要進行層次深入的更新操作

branches:分支既是從主幹上衍生出來的程式碼副倉庫，當然這個別稱有待商榷，但是它的目的是顯而易見的，就是為某些解決特定問題或者實現特殊功能的大牛們的專用倉庫，他們會在開發的工程中，從團隊的主幹中分離出來，進行特殊的工作，而為了不讓這些特殊的操作影響專案的進度和產品的上線，就從主幹上覆制一份當前的完整程式碼，交給某些人進行特殊功能的開發，如果在產品上線之前，這個分支的問題能夠得到很好的解決的話，就會將分支的功能模組合併到主幹上，為主幹增加光采，當然分支的另一個主要功能是進行不同階段的程式碼的備份

tag:標記是一個比較特殊的分支，儲存的都是已經上線的產品。比如產品1.0上線之後，大家當然要繼續埋頭苦幹為了2.0而加班加點，這個時候如果一旦發現1.0版本有很嚴重的bug，那麼這個時候的操作就是在1.0的tag版本上建立另外一個分支，在這個分支裡修改bug，同時主幹的工作必須繼續進行，儘快的進行產品bug的修復，之後將修改完的版本合併到主幹中去，這樣主幹的工作沒有收到影響，而且即時的解決了bug，並且以後的2.0版本也沒有這個同樣的bug了。

使用場景

場景一：客戶想對產品做定製，但我們並不想修改原有svn中trunk的程式碼

場景二：正在開發產品下階段的任務，但上階段的工作發現問題

如何操作

以svn客戶端最新版為例：

圖1

圖2

圖3

以場景二為例：專案某一階段開發完成後，這個時候需要做一個tag，比如說tag_V1.0，然後基於這個tag釋出一個新版本，trunk進入下階段繼續開發。但是很不幸釋出的版本被檢測出來了bug，有人會提議，把bug放到下階段的任務中去。假設下階段的任務才剛開始，使用者可等不起.他們會認為一個小的bug解決要這麼長時間,效率太低了。那麼就需要基於tag_V1.0做一個branch，branch_bugfix_V1.0，基於這個branch進行bugfix，等到bugfix結束，做一個tag，tag名稱假設為：tag_mf_V1.0,基於這個tag再釋出一個版本。這樣又沒有影響trunk(主分支)的開發。然後，根據需要決定branch_bugfix_V1.0是否併入trunk。