一：主幹釋出
先說主幹釋出模式： 以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可能會被破壞，但是如果有一套規範，可以把風險降到最低。（或者也可以透過開分支的方式來解決這種問題）
第三：如果想要真正發揮這種釋出模式的威力，配置管理，變更管理，持續整合，質量管理，釋出管理每一個模組都是不可少的。
