Git分支模型分析

前言

分支模型的抉择可以概括为围绕 持续集成 和 特性隔离 两个特征进行博弈。

分支模型对比结论

优缺点分析

TBD说明

使用分析

分支模型	主干数	特性分支数	集成频率	多版本并行开发	需求中途撤销	打包方式
Git Flow	2	5类	特性分支完成后一起集成	特性分支	合并前：删除特性分支 合并后：手动剔除代码	开发分支和发布分支分别打包
Aone FLow	1	3类	指定特性分支频繁集成	特性分支且控制合并时间	删除特性分支重新集成	发布分支分别打包
GitHub Flow	1	1类	特性分支立即集成	特性分支	手工剔除代码	特性分支打包
TBD	1	1类	所有提交立即集成	特性开关	手工剔除代码	一次打包多次部署

分支模型详细分析

GitFlow

详情参考

分支情况

• 主干分支（长期）
  • 主分支：master
  • 开发分支：develop
• 特性分支（短期）
  • 功能分支：feature
  • 预发分支：release
  • 补丁分支：hotfix

玩法

• 开发&发布
  • develop分支创建feature分支

* feature开发、测试完提pr到develop分支
* code review 和合并进develop
* 等待各个feature合并到develop
* develop创建release分支并进行测试
* release 开始发布，进行bug fix 且需要合并回develop
* release 发布完成，merge到master和develop

• 修复
  • 通过tag创建对应hotfix进行修复，然后合并回develop和master

GitHubFlow

详情参考

分支情况

主干分支：master
特性分支：feature

玩法

开发：主分支创建feature分支进行开发、PR、Review、发布完成后，建立PR回master
修复：特性分支未合入master前特性分支修复，合入后针对tag单开分支修复并合入主干分支

它有一个变种版本，更好的支持多环境和多版本 ，可以参考 GitLab Flow

TBD

详情参考

分支情况

主干分支：master

玩法

开发：所有团队成员都在单个主干分支上进行开发，
符合约定后commit到主干分支。也可创建短周期分支进行开发rebase主干分支后提交PR

发布：优先Tag，Tag不能满足则创建发布分支

修复：主干分支修复，cherry pick到发布分支，新tag与发布

其它辅助方案策略

• 如何避免引入未完成feature？ feature toggle（功能开关）
• 如果重构？ BBA（抽象分支）

AoneFlow

详情参考

分支情况

主干分支：master
特性分支：feature、release

玩法

• 开始工作前，从主干创建特性分支。
• 通过合并特性分支，形成发布分支。
• 发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。