簡介
? ? ? ?主干開發(fā)(trunk-based development TBD)。它的特點(diǎn)就是項目的功能開發(fā)工作主要在從master主分支上。
? ? ? ?根據(jù)功能代碼開發(fā)完畢后的項目發(fā)布，就出現(xiàn)了兩種不同的發(fā)布模式：
? ? ? ?? ? ? ?主干開發(fā)-主干發(fā)布
? ? ? ?? ? ? ?主干開發(fā)-分支發(fā)布

1. 主干開發(fā)-分支發(fā)布

主干開發(fā)-分支發(fā)布簡介
? ? ? ?主干開發(fā)-分支發(fā)布的特點(diǎn)就是項目的功能開發(fā)工作在master分支上，代碼開發(fā)完畢后，經(jīng)過功能測試沒有問題后，從master主分支上切出一個release分支，作為項目代碼版本發(fā)布的專用分支，而master分支還繼續(xù)做項目下一個功能版本的開發(fā)工作。
? ? ? ?如果線上代碼出現(xiàn)bug，那么就在release分支上修復(fù)就可以了，修復(fù)后的代碼最終要合并到主干上，只有非常嚴(yán)重的缺陷修復(fù)才會從master合并到release分支上。
? ? ? ?因?yàn)橹鞲纱a一致處于可發(fā)布狀態(tài)，所以更容易發(fā)布，而且，我們可以多個發(fā)布版本同時存在。
主干開發(fā)-分支發(fā)布效果

主干開發(fā)-分支發(fā)布原則

1. 項目所有主要/核心功能代碼的開發(fā)工作都在master分支上。
2. 項目重要功能發(fā)布的時候，從master單獨(dú)切出release分支，作為該功能的正式發(fā)布分支。
3. 項目正常運(yùn)行過程中出現(xiàn)功能(bug)問題，在相應(yīng)的release分支進(jìn)行bug的修復(fù)工作。
4. 項目新功能在測試發(fā)布前，必須先合并上一個release分支代碼。
5. 缺陷(bug)修復(fù)，最終需要合并到主干，但有些特定修改，是不需要合并到主干的，合并準(zhǔn)確的文件到主干。
6. 對于不能合并到主干的情況，視情況再拉一個分支專門保存該內(nèi)容。

優(yōu)勢：
? ? ? ?主干開發(fā)的過程中，關(guān)于分支合并的工作量很少，所以整體比較簡單
劣勢：
? ? ? ?新功能代碼在master主干上開發(fā)，若主干代碼達(dá)不到穩(wěn)定的標(biāo)準(zhǔn)，不可以進(jìn)行項目發(fā)布
使用場景：
? ? ? ?比較適合傳統(tǒng)軟件產(chǎn)品的開發(fā)模式的項目、多產(chǎn)品線的項目
? ? ? ?被廣泛的應(yīng)用于開源項目
? ? ? ?強(qiáng)烈推薦、業(yè)界標(biāo)準(zhǔn)

2. 主干開發(fā)-主干發(fā)布

主干開發(fā)-主干發(fā)布簡介
? ? ? ?主干開發(fā)-主干發(fā)布的特點(diǎn)就是項目的功能開發(fā)工作在master分支上，代碼開發(fā)完畢后，經(jīng)過功能測試沒有問題后，在master主分支上打release標(biāo)簽作為項目代碼版本進(jìn)行發(fā)布。發(fā)布完畢后，master主分支還繼續(xù)做項目下一個功能版本的開發(fā)工作。
? ? ? ?如果線上代碼出現(xiàn)bug，那么就在master分支上修復(fù)就可以了。
主干開發(fā)-主干發(fā)布效果

主干開發(fā)-主干發(fā)布原則：

1. 項目所有主要/核心功能代碼的開發(fā)工作都在master分支上，開發(fā)完畢后，在master分支上進(jìn)行集成測試
   。
2. 項目代碼測試通過后，通過打標(biāo)簽的方式，以標(biāo)簽的方式進(jìn)行代碼發(fā)布。
3. 項目正常運(yùn)行過程中出現(xiàn)bug，在master分支進(jìn)行bug的修復(fù)工作，修復(fù)代碼通過測試后，打標(biāo)簽發(fā)布。
   優(yōu)勢：
   ? ? ? ?效率最高的一種項目開發(fā)方式。
   ? ? ? ?項目代碼發(fā)布前，需要進(jìn)行主干集成測試，代碼沖突易于提前發(fā)現(xiàn)
   ? ? ? ?master主干代碼安全穩(wěn)定，每次測試通過后，都可以隨時發(fā)布。
   ? ? ? ?集成測試常見的配套措施：每日集成(編譯部署測試)，代碼檢查，單元/接口/界面自動化測試。
   劣勢：
   ? ? ? ?新功能代碼在master主干上開發(fā)，若主干代碼達(dá)不到穩(wěn)定的標(biāo)準(zhǔn)，不可以進(jìn)行項目發(fā)布master上主干開發(fā)有先后，有未完成的功能但又需要發(fā)布時，需要能隱藏未完成部分。
   為了避免以上情況，有三種緩解方法：
4. 功能拆分，小批量頻繁發(fā)布；
5. 后端先行，ui或功能入口發(fā)布；
6. 功能開發(fā)，配置決定功能

3. 生產(chǎn)案例

? ? ? ? 根據(jù)DevOps研究評估組織(DORA)連續(xù)多年對互聯(lián)網(wǎng)公司的IT效能的調(diào)研，全球數(shù)千家公司參與了該項調(diào)查，其中關(guān)于代碼配置管理的內(nèi)容，值得我們思考。
? ? ? ? 該組織調(diào)查了基于主干開發(fā)在持續(xù)交付過程中所起到的作用，根據(jù)以往數(shù)年的經(jīng)驗(yàn)，在高效能研發(fā)團(tuán)隊中，相比長期存在的特性分支，基于主線的小批量研發(fā)分支更加受到歡迎，行業(yè)中的很多先驅(qū)者傾向于把工作至于分支上。調(diào)查結(jié)果表明，以下開發(fā)實(shí)踐可以顯著幫助軟件交付變得更加高效：

1. 每天向主干合并一次代碼
2. 讓分支生命周期盡量短(少于一天)
3. 同一時間少于三條的活躍分支

4. 小結(jié)

分支開發(fā)分類：主干開發(fā)-分支發(fā)布、主干開發(fā)-主干發(fā)布
分支發(fā)布流程：開發(fā)-測試-拉取-發(fā)布-循環(huán)
主干發(fā)布流程：開發(fā)(拉取)-測試-發(fā)布-循環(huán)