一：主幹發布
先說主幹發布模式: 以svn庫為例,大致將庫分為trunk,branch,tag三種,主線發布就是公司要發布某個產品的v1版本,之前大家都做會在svn的trunk上做開發,等trunk穩定了.開出乙個分支b1,在b1分支上做v1版本的其它功能新增,bug修改等,並使用持續整合來驗證b1的穩定性.直到v1版本達到要求,可以對外發布,並且發布成功後,進行從branch到trunk的merge操作,此時trunk上的內容變成了v1版本的內容,而後trunk上的內容不再允許修改.然後,再發布v2,這個時候,比如下乙個版本要發布v2版,這時從trunk的v1版發布的那個點,開乙個分支b2出來,再進行v2版的開發,並做持續整合驗證v2版的穩定性.直到v2版也達到要求,並且對外發布以後,將b2merge到trunk上,此時的trunk上的內容又變成了v2版本的內容. 依次類推, 直到v3,v4,v5等.我們稱這種發布模式為主幹發布,因為主幹上的東西永遠都是發布後的產品,而且不允許修改.
如下圖:
如果按照這種方式發布的優點：
第一：可以隨時保證trunk上的東西的穩定性，使trunk隨時可用；
第二：大部分開發人員不會去觸碰trunk，用分支的方式解決實際開發過程中的一些變更（需求變更或設計變更等）；
第三：可以從trunk上隨時拿到已發布的任意乙個版本。
如果按照這種方式發布存在的不足:
第一：開發的時候, 持續整合一直在驗證著branch上的穩定性和正確性,而對於release完成後merge到trunk上後,沒有對trunk進行整合驗證, 難以保證trunk的穩定性；
第二：違背了svn的規範，把trunk庫當成了tag庫去使用；
第三：某些開源專案會採用這種開發（發布）模式，但其中對於驗證要求非常嚴格，merge起來很費時，鑑於開源專案的特殊性，暫不做討論；
第四：一般採用這種模式發布，是有自己的考慮在裡面的。那就是trunk上的東西是不能損壞的，必須隨時是好的，即使偶爾出現問題也能及時修正，但trunk已經完全失去了它做為主幹的意義，也很難保證svn庫的一致性。
二：分支發布
再說分支發布模式：以svn庫為例,大致將庫分為trunk, branch,tag三種,所有開發人員基於trunk進行開發,比如也是要發布v1版本的產品,到trunk上的內容穩定後,版本達到了要release的要求,這時從trunk上開分支出來,我們可以稱這個b1分支上的內容為pre-release版,此時這個b1分支只為fixbug,除非有必須要加的新功能.這個時候呢,大部分的開發人員就可以在trunk上開發下一次的發布, 而只需要少部分開發人員基於b1分支fixbug.如果有bug需要在b1和trunk裡面都fix的話,就會有少量的merge操作,如非必要,就省心了.b1分支開出來後,一旦release了,可以根據發布計畫,選擇是否需要保留.如果近期有發b1的update計畫,則可以保留;如果近期都不會再有基於b1的開發,可以將v1發布這一時刻點的b1狀態通過tag的方式記錄下來,然後消亡b1分支.我們稱這種模式為分支發布,因為分支才是發布的線,主幹可以一直進行開發,而沒有必要停止.
如下圖:
如果按照這種方式發布的優點：
第一：trunk做為開發主線，開發人員可以隨時將自己符合要求的**提交到trunk上，如果在沒有必要的條件下，不開分支。同時對trunk做持續整合驗證，最大程度上保證trunk的穩定性。
第二：對每次成功的持續整合都同時對庫和整合環境做tag操作，發揮tag庫的強大作用。
第三：最大量的減少了merge操作，降低了誤差。一旦要發布產品，只需從乙個穩定的版本（公司上層同意的）發乙個分支出來，然後再投入少量的開發人員去進一步優化，主要是fixbug。而這時，大部分開發人員就可以投入到下乙個版本的開發中,最大力度的使用人力資源。
第四：其它.
如果按照這種方式發布存在的不足:
第二：如果有大型的變更，trunk可能會被破壞，但是如果有一套規範，可以把風險降到最低。（或者也可以通過開分支的方式來解決這種問題）
第三：如果想要真正發揮這種發布模式的威力，配置管理，變更管理，持續整合，質量管理，發布管理每乙個模組都是不可少的。
原文觀點支援分支發布。
發布與分支
首先來說一下發布的概念，發布的是什麼呢，是故事 story 嗎？不是，是特性 feature 特性由乙個或多個故事組成，單個故事可以驗收，但是不能單獨上線。比如當你做完了購物車的故事，是不能把單獨把它上線的，因為你無法在購物車中進行結算。從使用者體驗的角度來說，這兩個故事要麼一起上，要麼都不上。而且...
SVN主幹和分支的合併
1 在svn倉庫下新建專案，結構如下 project 專案名 trunks 主幹，branches 分支 tags 標籤 2 主幹內容合併到分支 分支需要改變，則右鍵分支進行合併 選擇分支目錄，選擇合併，合併兩個不同的樹，起始處 from 選擇當前目錄中需要改變的目錄或檔案的url，結束處 to 選...
SVN 合併的思考 SVN 分支合併主幹
今天在使用 svn 的過程中遇到了這麼乙個問題 我們在乙個月前從主幹上拉出了乙個分支，乙個月的開發過去了，發現不論是分支還是主幹上都進行了非常繁雜的修改，此時我們的測試要求先把主幹上的 合併到分支上進行測試，那麼現在問題來了，如何將主幹上的 合併到分支上呢？有關 svn 的合併的問題，其實都可以在這...