在單純的開發階段時，乙個svn主幹就足夠了，團隊協作開發是沒有問題的。但是，當專案上線之後，乙個主幹就不能滿足需求了。
在開發過程中，如果要發布專案，是需要打包發布的，專案上線之後，會有一些新的需求需要開發，這些需求可能並不是當前階段要上線的，或者是還沒有經過測試環境測試的，是不允許打包到生產的程式包中的。但是現在只有一套**，如果打包的話，不能上線的**也會被打進去。這時，就應該區分開哪些是生產的**，哪些是開發時的**，這樣，打包發布的話，只需要打包生產的**就可以了。
這就用到了 svn 的分支管理。某個開發階段，**上線之後，將現階段的**拉出乙個分支，與開發主幹區分開，這樣，發布的話，只需要打包生產分支的**就可以了，開發分支中的**，可以繼續開發新需求，互不影響。
在大型的專案中，專案是迭代進行開發的。每開發到乙個階段，就要進行一系列的測試和發布。這個時候，分支的管理尤其重要。當開發到乙個階段之後，將主幹的**拉出乙個測試分支，放到 branches中，然後測試人員拉取分支的**，打包發布到測試環境，測試通過之後，將**合併到之前的生產分支中。如果測試過程中發現了bug，那麼就在該分支中進行修改，修復之後，再將**合併到生產分支和開發主幹中。而對於已經上線過的**，可以將**拉取分支放到tags中，進行生產版本的記錄。
目前考慮的管理模式是，生產上上線乙個版本之後，向tags中拉出乙個記錄，並且向 branches 中拉出乙個生產分支。如果生產版本有小的改動，那麼直接checkout生產分支**，更改測試完成之後，將**合併到主幹中。
也可以看下這兩位老哥的部落格，幫助理解和應用：
idea 中的分支管理，著重操作
svn的操作，有詳細的講解
分支的分配方法(推薦)：
trunk：專案主幹，主要作為開發的主幹**。
branches：分支，可以用作測試環境發布過程中的分支存放，或者bug修改時的分支。
tags：生產發布的版本記錄，用來存放生產發布了的版本。
另外一種分配方法：
trunk：專案主幹，用於存放已經沒有問題的**(經過測試的)。
branches：包含開發分支和測試分支，各分支中的**驗證沒有問題之後，可以合併到主幹中。然後主幹中選擇拉出乙個生產分支。
tags：生產發布的版本記錄。
注意：（1）如果要將生產分支合併到主幹，那麼應該開啟主幹**，svn – integrate file。
（2）分支合併到主幹之前，要先將分支上的**提交到svn，否則合併不到，以為是svn目錄直接進行合併，不會對比本地**。
1.整個專案的合併：
這時會報錯，因為版本不同，要求先更新。但是並沒有要更新的東西。而且，整個專案的合併，容易將別人的**也合併了，所以這種方式暫時不採用。
2.單個合併修改的檔案(推薦使用的方法)：
因為對於已經上線的生產分支，修改不會太大，所以，對於自己修改的檔案，進行合併分支操作，合併範圍更小，而且可以避免合併了別人的**。
方法就是，把生產分支和主幹**都checkout本地，在生產分支**改動完，並且測試通過之後，將生產分支改動的**都合併到主幹上去，這裡就要自己維護乙個主幹分支的改動**清單，如果忘記改動了**，可以通過local/svn history 檢視，或者在 idea 中 ctrl+e檢視編輯歷史。
注意：source2的路徑可能不正確(或者svn目錄沒有許可權)，需要自己找到真正的路徑，然後配置上去。
關於coding中分支的使用方法及專案更新命令
從專案 主頁中將專案git clone 加鏈結就可以了下來。鏈結位址如圖 3.git branch可以檢視當前分支，顯示是綠色的。如圖 4.如果你想push進入origin jixiang這個專案中，就使用命令git checkout track origin jixiang將但前分支改變成orig...
C 中分支的使用
分支使用 兩種分支的相同點和不同點 1 兩種都可以實現分支結構 2 if可以使用範圍進行分支處理,而switch 只能對值進行分支處理 1.if的使用和種類 if 可以巢狀使用 就是if執行體中再次進行if判斷,理論上可以無限巢狀 1 if 表示式 變數 判斷 值 是否為true,如果為true 則...
git zheda分支使用方法
value 01 是kitti資料集的編號 value media localization localization kittidataset 是kitti的資料位址，需要換成你自己的kitti目錄 data odometry velodyne下只有乙個dataset資料夾 1 dataset資料...