svn作爲版本控制軟件被廣泛用於衆多公司的開發團隊中，最多的場景就是一個項目上傳svn後，一個組內的小夥伴在上邊提交和更新代碼以及解決衝突，其實這只是發揮了svn的很小的一部分功能。
先稍微介紹一下svn的兩種開發和發佈的規範：
一 主幹修改，分支發佈
代碼都在trunk上修改，需要發佈的時候，從主幹上拉出一個版本，如果該版本發現BUG則繼續從該分支上修改，並將修改合併到主幹上。
二 主幹發佈，分支修改
任何修改都不能在主幹上直接進行，開發新功能，從主幹上分支出一個版本，進行開發，發開測試完畢後，在合併到主幹上。
個人比較推崇第二種，其優勢在於各個分支獨立進行，互不干擾，可以使不同開發週期的應用在同一個項目中開發進行。對於同一個應用，a組人開發完畢，b組人只做了一半，這個時候，對於主幹修改，分支發佈，這樣是根本不能發佈出去的，而對於主幹發佈，分支修改，只需要把a組的修改合併回主幹就可以發佈出去了，b組開發的根本不受影響。
下面介紹一下分支，合併的應用場景，並針對場景進行一個小栗子。
場景1： 採用主幹發佈，分支修改的規範後，項目要新開發一個功能，這時候我拉開了一個分支，開發完畢後要分支代碼合併回主幹。
場景2：我在分支的開發過程中，主幹被其他的項目組進行較大的改動，爲了避免在“正確”（trunk）的道路上走歪了，也爲了避免最終合併代碼的時候，太過麻煩，我需要將主幹的代碼合併到分支上來。
場景3：對於同一個文件，同一個方法內的代碼合並的時候衝突問題解決。
案例：事先準備工作，我需要在svn創建一個項目test，並創建一個分支test2.0 如圖，項目右鍵--Team-分支
然後刷新一下svn倉庫，對比看一下trunk主幹和branches分支裏面多了一個2.0的test
場景1 分支代碼合併回主幹。
項目右鍵-team-先切換到分支代碼，然後將分支代碼進行改動，然後在切換回主幹代碼，進行合併操作，如圖
然後將分支的修改代碼提交svn一下，然後同樣切換回主幹trunk代碼，準備合併。
切換回主幹代碼後，分支代碼修改的地方，主幹代碼不受影響，還是老樣子。
右鍵team-選擇合併，然後選擇第二個選項：分支合併到主幹
這時候，你就會看到分支的代碼被合併到主幹上來了，然後提交svn就可以了
場景2：就不介紹了，唯一的區別就是選擇合併方式的時候，選擇第一個選項就可以了
場景3：衝突解決
再次切換到分支代碼，將分支代碼更改
然後切換到主幹代碼trunk，項目右鍵-team-合併，選擇第二項，分支合併到主幹，next。就會出現如下圖結果，將衝突解決完後，右鍵-》標記爲解決衝突
衝突的代碼就解決完了。
最後附帶merge input 合併類型截圖
