關於代碼管理的分支和發佈策略，目前我知道的主要有兩種模式。
一種是主幹做爲新功能開發主線，分支用做發佈。
另外一種是分支用做新功能開發，主幹做爲穩定版的發佈。
前一種分支管理策略被普遍的應用於開源項目。好比freebsd的發佈就是一個典型的例子。freebsd的主幹永遠是current，也就是包括所 有最新特性的不穩定版本。而後隨着新特性的逐步穩定，達到一個發佈的里程碑之後，從主幹分出來一個stable分支。freebsd是每一個大版本一個分 支。也就是說4.x，5.x，6,x各一個分支。每一個發佈分支上只有bug修改和現有功能的完善，而不會再增長新特性。新特性會繼續在主幹上開發。當穩定 分支上發生的修改積累到必定程度之後，就會有一次發佈。發佈的時候會在穩定分支上再分出來一個release分支。以6.x爲例，就會有 6.0,6.1,6.2…等發佈分支。
這種發佈方法很是適用於產品線的發佈管理。產品是要賣的，之前賣給客戶的版本仍須要繼續維護，而爲了之後的市場，新功能也不斷地在增長。這種管理方法 對已發佈產品的維護工做和下一代產品的開發工做進行了隔離。對於已經發布的產品，只有維護的補丁發佈。而新發行的產品不只包括了全部的bug修改，還包括 了新功能。
這種方法也不是沒有缺點的。首先，必須對主幹上的新功能增長進行控制。只能增長下一個發佈裏面計劃集成進去的新特性。並且，已經在主幹上集成的新特性 中的任何一個，若是達不到里程碑的要求，穩定分支就不能建立，這頗有可能影響下一個發佈的計劃。開源項目可能這方面的壓力小一些，可是商業產品開發若是碰 到這種狀況就危險了。還有一個缺點就是bug修改必須在各個分支之間合併。從分支和合並的一些實踐經驗上看，各個長期存在的分支之間必需要週期性的進行合 並，不然很容易引起合併衝突。但是各個stable分支以及release分支之間剛好是不能進行合併並且還要長期存在的。所以，採用這種分支策略可能碰 到的最大問題就是某個分支上的bug修改內容往其它分支merge的時候出現的衝突。並且一旦發現一個bug，調查這個bug影響哪些分支的工做會隨着維 護的發佈分支的數量而增長。
在非產品開發的外包軟件項目裏面，這種發佈方法的好處體現不出來，而缺點仍然存在。外包項目的特色是客戶永遠須要「最新」的代碼，所以對已經發布的某 個分支進行維護的狀況不多出現（在測試的時候會出現）。並且發佈的方法和產品的發佈也不同。產品的發佈，只要把發佈分支上的代碼編譯成安裝盤就能夠了， 而外包的發佈每每是把上一次發佈和這一次發佈之間發生變化的代碼送給客戶。若是每次發佈都是一個分支的話，將會出現兩個分支上的比較。強大的版本控制工具 固然支持這種比較，可是不少版本工具不支持分支之間的比較，而只支持分支內的不一樣版本之間的比較。所以爲了不發佈方法受工具的限制，就要避免出現分支間 比較的狀況。針對外包開發的特殊狀況，只有採用另一種分支管理策略。
與第一種分支策略正好相反，主幹上永遠是穩定版本，能夠隨時發佈。bug的修改和新功能的增長，所有在分支上進行。並且每一個bug和新功能都有不一樣的開發分支，徹底分離。而對主幹上的每一次發佈都作一個標籤而不是分支。分支上的開發和測試完畢之後才合併到主幹。
這種發佈方法的好處是每次發佈的內容調整起來比較容易。若是某個新功能或者bug在下一次發佈以前沒法完成，就不可能合併到主幹，也就不會影響其餘變 更的發佈。另外，每一個分支的生命期比較短，惟一長期存在的就是主幹，這樣每次合併的風險很小。每次發佈以前，只要比較主幹上的最新版本和上一次發佈的版本 就可以知道此次發佈的文件範圍了。
這種發佈模式也有缺點。若是某個開發分支由於功能比較複雜，或者應發佈計劃的要求而長期沒有合併到主幹上，極可能在最後合併的時候出現衝突。所以必須 時刻注意分支離開主幹的時間。若是有的分支確實由於特殊的須要必須長期存在，那就必須按期把主幹的更新往這個分支上合併。爲了減小這種合併發生的次數，並 且限定合併的範圍，要爲每次發佈預先創建一個發佈分支，而後全部的開發分支根據本身的發佈計劃向各個發佈分支合併。當下一次發佈的分支上已經集成了全部的 變動而且測試完畢之後，把這個發佈分支內容合併到主幹，發佈主幹，而後鎖定或者刪除這個分支。而後把主幹上的全部更新合併到後面幾個發佈分支裏面去。外包 項目的發佈週期通常都比較短，每每客戶驗收測試的週期就是發佈週期。因此這種方法就夠用了。若是發佈週期很長，各個發佈分支之間還要按期的從前向後合併。 這種發佈方法還有一個缺點就是測試。不像第一種分支策略，發佈的分支就是測試的分支。這種發佈模式的測試分支每每是各個發佈分支，在正式發佈以前 才把下一個發佈分支上的更新合併到主幹，這就引入了合併出錯的風險，而主幹上的程序是沒有通過測試的。幸虧從這個發佈模式上看，下一個發佈分支的合併基礎 應該和主幹上一次發佈內容相同，因此引入合併錯誤的風險很低。還有一種建議就是不設置主幹，下一個發佈分支就是主幹，直接發佈下一個發佈分支的變動內容， 而後把變動合併到再下一個發佈分支上去。以此類推。有機會嘗試一下。
最後，說說分支合併管理的一些注意點：
1.分支離開主幹的時間要儘量短。長期離開主幹的分支須要按期合併。
2.輔助文檔是必需的。爲了觀察分支的建立和合並的過程，至少須要一份相似泳道圖的文檔標記每一次分支建立和合並的過程。
3.開發分支往主幹或者發佈分支合併的次數應該儘量少。通常來說應該在單體測試結束合併到主幹或者發佈分支，而後進行結合測試。若是結合測試裏發現bug不該該在原來的開發分支上繼續修改，而應該建立新的分支進行修改。
4.分支建立和合並的log必須規範。便於之後查找。基本的log信息應該包括從哪一個個分支的哪一個版本建立分支；把哪一個分支的從哪版本到哪一個版本範圍 內的變動合併到了哪一個分支的哪一個版本，合併後的版本號。這些信息有一些是版本控制工具自己能夠很方便查找到的，就能夠省略。 併發