原始碼主幹分支開發四大模式
阿新 • • 發佈：2019-01-27
1，先鋒主幹多穩定分支；2，守護主幹多先鋒分支；3，主幹無分支；4，守護主幹單分支。
一、先鋒主幹多穩定分支
得到一個穩定版本後，將此穩定版本放到一個新分支上，針對此穩定版本的修修補補就在這個分支上進行，新功能不在此分支上開發，而在主幹上進行新功能的開發。 這是業界採用較多的模式。
穩定分支上的有些修改，比如缺陷修復，需要合併到主幹， 但有些特定修改，是不需要合併到主幹的。這時需要千萬注意，合併準確的檔案到主幹。
對於不能合併到主幹的情況，常見的是再拉一個分支，這個分支專門為少數特定情況而用，但從全域性講，可能會導致太多分支，不同分支間混亂，所以這並不推薦。推薦寧願採用配置開關。
圖片來源於 http://blog.csdn.net/binnacler/article/details/4274486
比如freebsd的釋出就是一個典型的例子。
freebsd的主幹永遠是current，也就是包括所有最新特性的不穩定版本。然後隨著新特性的逐步穩定，達到一個釋出的里程碑以後，從主幹分出來一個stable分支。freebsd是每個大版本一個分支。也就是說4.x，5.x，6,x各一個分支。每個釋出分支上只有bug修改和現有功能的完善，而不會再增加新特性。新特性會繼續在主幹上開發。當穩定分支上發生的修改積累到一定程度以後，就會有一次釋出。釋出的時候會在穩定分支上再分出來一個 release分支。以6.x為例，就會有6.0,6.1,6.2…等釋出分支。【此段摘自於網路 http://thinkernel.bokee.com/4518935.html 】
二、守護主幹多先鋒分支
得到一個穩定版本後，拉出先鋒分支，在分支上開發新功能，在主幹上進行修修補補。當先鋒分支通過一定的測試之後，合併到主幹。可以同時有多個先鋒分支，不同的功能可以拉不同的分支，不同釋出時間點而又要同時開發的內容必須在不同的分支上。從釋出的角度講，更推薦將肯定一起釋出的內容放在相同的先鋒分支上。主幹上永遠是穩定版本，可以隨時釋出。bug的修改和新功能的增加，全部在分支上進行。而且每個bug和新功能都有不同的開發分支，完全分離。而對主幹上的每一次釋出都做一個標籤而不是分支。分支上的開發和測試完畢以後才合併到主幹。這種釋出方法的好處是每次釋出的內容調整起來比較容易。如果某個新功能或者bug在下一次釋出之前無法完成，就不可能合併到主幹，也就不會影響其他變更的釋出。另外，每個分支的生命期比較短，唯一長期存在的就是主幹，這樣每次合併的風險很小。每次釋出之前，只要比較主幹上的最新版本和上一次釋出的版本就能夠知道這次釋出的檔案範圍了。
【此段摘自於網路 http://thinkernel.bokee.com/4518935.html 】
三、主幹無分支
只有主幹，沒有分支，所有緊急正常的修改全在主幹上，開發了一半的東西如果要上線的話，要巧妙的藏起來。對程式的結構提出了高要求，分分合合要方便，開關配置是少不了的了。單從效率講，這是最高效的模式了。要有不少配套措施才可以。常見的配套措施：每日整合（編譯部署測試），靜態程式碼檢查，測試不僅僅有單元測試，還有介面測試，還有介面自動化測試。四、守護主幹單分支
只有一個分支，緊急修改在主幹上進行，正常開發在分支上進行，主幹和分支根據需要雙向同步。需要採用與主幹無分支相同的配套手段，而且在主幹和分支上都需要建設每日整合，甚至持續整合。以上四種模式是主幹分支開發的典型情況。在實際應用中，前2種更加常見一些，主幹無分支開發時碰到極其特殊情況時，不排除拉短分支。而在第一個模式先鋒主幹穩定分支開發時與第三個模式主幹無分支，是可以在一段時間內相互轉換的。參考資料1，程式碼的分支管理策略 http://thinkernel.bokee.com/4518935.html