最近專案用上了svn分支管理，因為專案太過龐雜，版本迭代也過於頻繁，致使多個版本的**交雜在一起，難以維護，無法保證其中某個版本的穩定性。當然，我們也用過很土的辦法，**複製乙份出來，但是，這個副本也需要加上新開發的功能。
所以，我們決定使用svn分支管理。當然，這有代價，svn版本管理對二進位制檔案不友好，可能檔案分支合併時二進位制檔案會難以處理。（這裡說的二進位制檔案，泛指所有非文字檔案，比如說美術資源，策劃文件）
使用分支最主要的目的是，多個分支可以並行，相互不干擾，而且任何時候都可以合併。其次，容易保證主幹的穩定性。
沒有分支的時候，你的svn可能是這樣的：
就乙份**存在主幹（trunk），當然也不會有主幹這個說法。開發完1.0，繼續開發2.0，版本乙個乙個迭代。
有了分支後，你的svn可能就是這樣的了：
主幹用來存放穩定的**，每個版本都會開乙個分支，等版本完成後再合併到主幹。版本乙個乙個迭代，但可以並行開發。
接下來，簡單講解下 如何使用svn做分支管理。
第一步，建立主幹分支目錄結構
第二步，建立分支
在主幹目錄 trunk 右鍵，在svn選單選擇branch/tag...
步驟①是分支位址，這裡直接以 /branches/1
步驟②是取trunk版本，head revision表示最新版本，其他可通過 show log選擇
執行 ok 後，到branches 目錄 svn update 就可以看到最新的分支了。
第三步，合併分支到主幹
分支就是開發目錄了，現在分支提交乙個檔案做測試。
然後，合併這個檔案分支到主幹。
現在到主幹目錄，右鍵svn選單選merge...
這個是將分支或主幹的修改合併到當前工作目錄，繼續如下。
接下來點完成，如果沒衝突的話，分支檔案就合到主幹了。
但這裡還要乙個操作，就是在主幹提交分支合過來的檔案。
題外話，之所以要有這一步，除了對分支內容進一步修改，還可以同時合併多個分支。選擇權交給使用者。
另外，主幹內容合到分支，也是使用merge 命令。
根據專案的不同，實際上的分支架構也會不同。以我們專案為例，我們是做遊戲的，專案過於龐雜，版本迭代非常頻繁。在版本1.1還沒完成時，我們可能就要開發2.0版本，這樣，版本1.1和版本2.0就要並行開發。而且，我們對穩定性有非常高的要求。
為此，我們設計了這樣的svn架構。
測試分支
為了保證主幹穩定，我們加了測試分支（如 rel_1.1的測試分支為 rel1.1_test ）。測試分支1.1是在分支1.1開發結束後開的，等待測試修復bug完成後，就會把測試分支1.1合入主乾及分支1.1。合併完成後，這個測試分支將會關閉。
多分支並行
因為專案需求較多，版本迭代繁雜，所以在版本1.1還沒結束時，就開了版本2.0的分支。當分支2.0需要測試合併到主幹時，就會從主幹合併最新的檔案到2.0測試分支，測試通過後，再合併到主幹。
分支合併的時機
對我們而言，不同分支的最大區別是功能上線的時間點。我們根據上線週期劃分功能，拆分到不同分支。因為開發需求多，迭代過於頻繁，所以靠後的分支對比之前的分支通常只是多了某些新功能。這樣，分支的出現，避免了未開發完成的功能影響了已開發完的功能，導致當前版本的不穩定。所以，合併分支的時機就是這個分支的功能要不要上線。
這樣，主幹永遠是穩定的，也只有經過測試的內容，才會合入主幹。同時，多個版本也可以並行。
參考：
SVN 分支管理
平時在工作中使用 svn 只是限於 commit，update 這樣的操作，至多再 reslove 解決一下衝突，沒有用過分支管理。開發過程中一般都是乙個功能開發完成之後整體進行提交，而最近在專案中有乙個比較大並且開發周期比較長的功能，所以在功能沒有完成之前不方便進行提交，所以想到了使用分支管理，邊...
svn分支的使用
建立分支 客戶端已checkout出來的要建立分支的資料夾，郵件，branch tag,topath中輸入要建立分支的路徑 例如原路徑 yutong product config sourcecode testweb 新路徑 yutong product config sourcecode test...
SVN的管理與使用
svn 2.每個專案有乙個repository 庫 首先要create repository 建立庫 2.1右鍵 tortoisesvn create repository here 建立乙個倉庫 2.2右鍵 svn checkout 檢出專案 3.svn的增刪改查 增加 將要新增的檔案放到從svn...