前言
分支模型的抉擇可以概括為圍繞 持續(xù)集成 和 特性隔離 兩個(gè)特征進(jìn)行博弈杯瞻。
分支模型對比結(jié)論
優(yōu)缺點(diǎn)分析
使用分析
| 分支模型 | 主干數(shù) | 特性分支數(shù) | 集成頻率 | 多版本并行開發(fā) | 需求中途撤銷 | 打包方式 |
|---|---|---|---|---|---|---|
| Git Flow | 2 | 5類 | 特性分支完成后一起集成 | 特性分支 | 合并前：刪除特性分支 合并后：手動剔除代碼 | 開發(fā)分支和發(fā)布分支分別打包 |
| Aone FLow | 1 | 3類 | 指定特性分支頻繁集成 | 特性分支且控制合并時(shí)間 | 刪除特性分支重新集成 | 發(fā)布分支分別打包 |
| GitHub Flow | 1 | 1類 | 特性分支立即集成 | 特性分支 | 手工剔除代碼 | 特性分支打包 |
| TBD | 1 | 1類 | 所有提交立即集成 | 特性開關(guān) | 手工剔除代碼 | 一次打包多次部署 |
分支模型詳細(xì)分析
GitFlow
分支情況
- 主干分支（長期）
- 主分支：master
- 開發(fā)分支：develop
- 特性分支（短期）
- 功能分支：feature
- 預(yù)發(fā)分支：release
- 補(bǔ)丁分支：hotfix
玩法
- 開發(fā)&發(fā)布
- develop分支創(chuàng)建feature分支
* feature開發(fā)甜橱、測試完提pr到develop分支
* code review 和合并進(jìn)develop
* 等待各個(gè)feature合并到develop
* develop創(chuàng)建release分支并進(jìn)行測試
* release 開始發(fā)布送爸，進(jìn)行bug fix 且需要合并回develop
* release 發(fā)布完成，merge到master和develop
- 修復(fù)
- 通過tag創(chuàng)建對應(yīng)hotfix進(jìn)行修復(fù)燥滑，然后合并回develop和master
GitHubFlow
分支情況
主干分支：master
特性分支：feature
玩法
開發(fā)：主分支創(chuàng)建feature分支進(jìn)行開發(fā)甩骏、PR诈皿、Review、發(fā)布完成后欠雌，建立PR回master
修復(fù)：特性分支未合入master前特性分支修復(fù)蹄梢，合入后針對tag單開分支修復(fù)并合入主干分支
它有一個(gè)變種版本，更好的支持多環(huán)境和多版本 富俄，可以參考 GitLab Flow
TBD
分支情況
主干分支：master
玩法
開發(fā)：所有團(tuán)隊(duì)成員都在單個(gè)主干分支上進(jìn)行開發(fā)禁炒，
符合約定后commit到主干分支。也可創(chuàng)建短周期分支進(jìn)行開發(fā)rebase主干分支后提交PR
發(fā)布：優(yōu)先Tag霍比，Tag不能滿足則創(chuàng)建發(fā)布分支
修復(fù)：主干分支修復(fù)幕袱，cherry pick到發(fā)布分支，新tag與發(fā)布
其它輔助方案策略
- 如何避免引入未完成feature悠瞬？ feature toggle（功能開關(guān)）
- 如果重構(gòu)们豌？ BBA（抽象分支）
AoneFlow
分支情況
主干分支：master
特性分支：feature、release
玩法
- 開始工作前浅妆，從主干創(chuàng)建特性分支玛痊。
- 通過合并特性分支，形成發(fā)布分支狂打。
- 發(fā)布到線上正式環(huán)境后擂煞，合并相應(yīng)的發(fā)布分支到主干，在主干添加標(biāo)簽趴乡，同時(shí)刪除該發(fā)布分支關(guān)聯(lián)的特性分支对省。
