在SVN裡面我們一般會創建出三個資料夾 Trunk（主幹）Branch（分支）TAG 在我們專案一開始的時候我們會將程式碼檔案（這邊暫時不涉及文件的管理）放在Trunk底下。然後我們就不斷的開始工作了。 按我的經驗的話我們用到Branch有兩種情況 專案穩定了要relase了整個業務流程和功能都是完成的。(基本看不到bug只有一些隱藏的很差的bug可能還存在，比如一些數值算錯)。這個時候我們就可以把這個Relase的版本放到Branch哪邊，然後我們繼續在trunk開發新的功能需求。relase哪邊只能是等待一些很小的bug。（測試和開發做得好的話。無限趨近0零）。 專案開發過程中，突然有一個大的需求過來。跟其它的需求沒有太大的關係。並且客戶想看一下這個功能做出來是否用得還可以。哪麼我們就可以從trunk這邊弄出一個branch然後，某個人或幾個人就工作在這個branche上面。客戶測試過後對這個Branche滿意之後。（也是大部分沒有bug）。然後合併到trunk. 如果branch的建立沒有按這種方式來搞的話。你會發現到時候合併起來的壓力是超級大的。合併的時候會漏掉一些程式碼，衝突N多。合併的人痛苦。團隊的其他成員也痛苦。 一個Relase釋出之後。經過一小段時間的修改。發現都沒有bug了。然後我們把這個Relase可以弄一個分支到Tag哪邊。實際我覺得這個意義不是很大。
在SVN裡面我們一般會創建出三個資料夾 Trunk（主幹）Branch（分支）TAG 在我們專案一開始的時候我們會將程式碼檔案（這邊暫時不涉及文件的管理）放在Trunk底下。然後我們就不斷的開始工作了。 按我的經驗的話我們用到Branch有兩種情況 專案穩定了要relase了整個業務流程和功能都是完成的。(基本看不到bug只有一些隱藏的很差的bug可能還存在，比如一些數值算錯)。這個時候我們就可以把這個Relase的版本放到Branch哪邊，然後我們繼續在trunk開發新的功能需求。relase哪邊只能是等待一些很小的bug。（測試和開發做得好的話。無限趨近0零）。 專案開發過程中，突然有一個大的需求過來。跟其它的需求沒有太大的關係。並且客戶想看一下這個功能做出來是否用得還可以。哪麼我們就可以從trunk這邊弄出一個branch然後，某個人或幾個人就工作在這個branche上面。客戶測試過後對這個Branche滿意之後。（也是大部分沒有bug）。然後合併到trunk. 如果branch的建立沒有按這種方式來搞的話。你會發現到時候合併起來的壓力是超級大的。合併的時候會漏掉一些程式碼，衝突N多。合併的人痛苦。團隊的其他成員也痛苦。 一個Relase釋出之後。經過一小段時間的修改。發現都沒有bug了。然後我們把這個Relase可以弄一個分支到Tag哪邊。實際我覺得這個意義不是很大。