先說主干發(fā)布模式: 以SVN庫為例,大致將庫分為trunk, branch,tag三種,主線發(fā)布就是公司要發(fā)布某個產(chǎn)品的V1版本,之前大家都做會在SVN的trunk上做開發(fā),等trunk穩(wěn)定了.開出一個分支B1,在B1分支上做V1版本的其它功能添加,bug修改等,并使用持續(xù)集成來驗證B1的穩(wěn)定性.直到V1版本達到要求,可以對外發(fā)布,并且發(fā)布成功后,進行從branch到trunk的merge操作,此時trunk上的內(nèi)容變成了V1版本的內(nèi)容,而后trunk上的內(nèi)容不再允許修改.然后,再發(fā)布V2,這個時候,比如下一個版本要發(fā)布V2版,這時從trunk的V1版發(fā)布的那個點,開一個分支B2出來,再進行V2版的開發(fā),并做持續(xù)集成驗證V2版的穩(wěn)定性.直到V2版也達到要求,并且對外發(fā)布以后,將B2merge到trunk上,此時的trunk上的內(nèi)容又變成了V2版本的內(nèi)容. 依次類推, 直到V3,V4,V5等.我們稱這種發(fā)布模式為主干發(fā)布,因為主干上的東西永遠都是發(fā)布后的產(chǎn)品, 而且不允許修改.

如下圖: 

如果按照這種方式發(fā)布的優(yōu)點：

第一：可以隨時保證trunk上的東西的穩(wěn)定性，使trunk隨時可用；

第二：大部分開發(fā)人員不會去觸碰trunk，用分支的方式解決實際開發(fā)過程中的一些變更（需求變更或設(shè)計變更等）；

第三：可以從trunk上隨時拿到已發(fā)布的任意一個版本。

如果按照這種方式發(fā)布存在的不足:

第一: 開發(fā)的時候, 持續(xù)集成一直在驗證著Branch上的穩(wěn)定性和正確性,而對于release完成后merge到trunk上后, 沒有對trunk進行集成驗證, 難以保證trunk的穩(wěn)定性；

第二：違背了SVN的規(guī)范，把trunk庫當成了tag庫去使用；

第三：某些開源項目會采用這種開發(fā)（發(fā)布）模式，但其中對于驗證要求非常嚴格，merge起來很費時，鑒于開源項目的特殊性，暫不做討論；

第四：一般采用這種模式發(fā)布，是有自己的考慮在里面的。那就是trunk上的東西是不能損壞的，必須隨時是好的，即使偶爾出現(xiàn)問題也能及時修正，但trunk已經(jīng)完全失去了它做為主干的意義，也很難保證SVN庫的一致性。

二：分支發(fā)布

   再說分支發(fā)布模式: 以SVN庫為例,大致將庫分為trunk, branch, tag三種,所有開發(fā)人員基于trunk進行開發(fā),比如也是要發(fā)布V1版本的產(chǎn)品,到trunk上的內(nèi)容穩(wěn)定后,版本達到了要release的要求,這時從trunk上開分支出來,我們可以稱這個B1分支上的內(nèi)容為pre-release版,此時這個B1分支只為fixbug, 除非有必須要加的新功能.這個時候呢,大部分的開發(fā)人員就可以在trunk上開發(fā)下一次的發(fā)布,而只需要少部分開發(fā)人員基于B1分支fix bug.如果有bug需要在B1和trunk里面都fix的話,就會有少量的merge操作,如非必要,就省心了. B1分支開出來后,一旦release了,可以根據(jù)發(fā)布計劃,選擇是否需要保留.如果近期有發(fā)B1的update計劃,則可以保留;如果近期都不會再有基于B1的開發(fā),可以將V1發(fā)布這一時刻點的B1狀態(tài)通過tag的方式記錄下來,然后消亡B1分支.我們稱這種模式為分支發(fā)布,因為分支才是發(fā)布的線,主干可以一直進行開發(fā),而沒有必要停止.

如下圖:

如果按照這種方式發(fā)布的優(yōu)點：

第一：trunk做為開發(fā)主線，開發(fā)人員可以隨時將自己符合要求的代碼提交到trunk上，如果在沒有必要的條件下，不開分支。同時對trunk做持續(xù)集成驗證，最大程度上保證trunk的穩(wěn)定性。

第二：對每次成功的持續(xù)集成都同時對庫和集成環(huán)境做tag操作，發(fā)揮tag庫的強大作用。

第三：最大量的減少了merge操作，降低了誤差。一旦要發(fā)布產(chǎn)品，只需從一個穩(wěn)定的版本（公司上層同意的）發(fā)一個分支出來，然后再投入少量的開發(fā)人員去進一步優(yōu)化，主要是fixbug。而這時，大部分開發(fā)人員就可以投入到下一個版本的開發(fā)中,最大力度的使用人力資源。

第四：其它.

如果按照這種方式發(fā)布存在的不足:

第一：配置管理需要隨時了解pre-release的分支是否需要保留，以為下一次發(fā)布update等做準備。

第二：如果有大型的變更，trunk可能會被破壞，但是如果有一套規(guī)范，可以把風險降到最低。（或者也可以通過開分支的方式來解決這種問題）

第三：如果想要真正發(fā)揮這種發(fā)布模式的威力，配置管理，變更管理，持續(xù)集成，質(zhì)量管理，發(fā)布管理每一個模塊都是不可少的。

原文：http://blog.sina.com.cn/s/blog_5eb1a2670100ewcs.html