一：主干發布
先說主干發布模式: 以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分支fix bug.如果有bug需要在B1和trunk里面都fix的話,就會有少量的merge操作,如非必要,就省心了. B1分支開出來后,一旦release了,可以根據發布計划,選擇是否需要保留.如果近期有發B1的update計划,則可以保留;如果近期都不會再有基於B1的開發,可以將V1發布這一時刻點的B1狀態通過tag的方式記錄下來,然后消亡B1分支.我們稱這種模式為分支發布,因為分支才是發布的線,主干可以一直進行開發,而沒有必要停止.
如下圖:
如果按照這種方式發布的優點：
第一：trunk做為開發主線，開發人員可以隨時將自己符合要求的代碼提交到trunk上，如果在沒有必要的條件下，不開分支。同時對trunk做持續集成驗證，最大程度上保證trunk的穩定性。
第二：對每次成功的持續集成都同時對庫和集成環境做tag操作，發揮tag庫的強大作用。
第三：最大量的減少了merge操作，降低了誤差。一旦要發布產品，只需從一個穩定的版本（公司上層同意的）發一個分支出來，然后再投入少量的開發人員去進一步優化，主要是fixbug。而這時，大部分開發人員就可以投入到下一個版本的開發中,最大力度的使用人力資源。
第四：其它.
如果按照這種方式發布存在的不足:
第一：配置管理需要隨時了解pre-release的分支是否需要保留，以為下一次發布update等做准備。
第二：如果有大型的變更，trunk可能會被破壞，但是如果有一套規范，可以把風險降到最低。（或者也可以通過開分支的方式來解決這種問題）
第三：如果想要真正發揮這種發布模式的威力，配置管理，變更管理，持續集成，質量管理，發布管理每一個模塊都是不可少的。