Git分支管理规约就像红绿信号灯为道路上的行人、司机提供通行指导一样，为版本快速迭代、稳定部署提供了操作指导。

对于版本发布的项目，往往侧重于保障发布运行的稳定性，并会结合版本规约对历史发行构件的兼容性进行严格的管理控制。

一、Git分支模型

基于git flow 分支模型理论基础，常用的分支有2个长期分支（master、develop），3个短期分支（feature、hotfix、release）。

1、两个长期分支

（1）master分支：主分支，包含稳定的发布版本

（2）develop分支：开发分支，基于master分支初始化，包含最新开发版本

2、三个短期分支

（1）feature/xxx：功能特性分支，基于develop分支初始化，进行相关特性功能开发。完成后需要并入develop分支

（2）hotfix/xxx：紧急修复分支，基于master分支初始化，进行正式环境紧急事项修复（例如：事故性缺陷、影响严重的功能优化）。完成后需要并入master与develop分支

（3）release/xxx：版本发布分支，基于develop分支初始化，进行预发版本进行功能测试、BUG修复直至完成封版（由预发版号变更为正式版号），最终并入master与develop分支

二、Git Flow模型示意图

三、扩展分支模型

随着业界理论模型的实践，额外又演进出了1个短期分支（bugfix）、1个长期分支（support）。

1、缺陷修复分支（bugfix）：是一种短期分支，基于develop分支初始化，进行正式环境的非事故性缺陷修复。完成后需要并入develop分支（分支管理与feature/xxx类似，可以视为一种特殊的功能特性分支）

2、版本支持分支（support）：是一种长期分支，基于tag进行初始化，进行多版本并行维护。通常在进行主版本升级时，如果需要并行维护上一个主版本，可基于上一个主版本的最新tag创建support/xxx分支，独立进行升级维护（次版本有独立维护需要时类似）

四、版本支持分支模型示意图

点击查看