以GitFlow分支模型为基准的Git版本分支管理流程

GitFlow分支模型中的主要概念

• master分支：为生产环境运行分支代码,只能有一个

• develop分支：主干分支,只能有一个

• feature分支：特性分支,可以有多个,每个工作项一个分支

• release分支：发布分支,可以有多个，测试用

• hotfix分支：热修复分支,可以有多个,用于生产环境出现问题时快速修复

• bugfix分支：发布分支时使用的bug修复分支

GitFlow的分支管理流程图

版本号说明

x.y.z-[state]

• x.y.z 为各版本的序号
• state 可选段，用来表示当前软件的状态。例如：b 表示bate版，即测试版。

x、y、z为非负整数

序号	说明
x	主版本号(major)无法向下兼容时，需要递增
y	次版本号(minor)新增新的特性时，需要递增
z	修订版本号(patch)修复问题时，需要递增

state的取值

• alpha : 内测版，Bug多
• beta ：公测版，有缺陷
• 没有state，代表正式版

借助插件Git Flow Integration Plus实现分支模型管理

1. 配置Git Flow
   

2. 在通过右下角的Gitflow插件开启分支。

3. 提交本地变更

4. 在通过右下角的Gitflow插件实现版本的合并。

5. 推送至远程仓库，记得推送标记。

其他模型

TBD模型

TBD模型只有一个主分支(master)和多个发布分支(release)，这种模式主要在集中式管理工具里使用的比较多,所有开发人员都在一个分支工作，并提交代码到一个分支，这种模式对开发人员的协调沟通要求较高。

阿里AoneFlow模型

AoneFlow模型是基于上述两种模型演变出来的一种新模型,核心内容如下:

1. master分支: 1个 主干分支
2. feature分支: 多个 特性分支
3. release分支: 多个 发布分支

工作流程:

1. 有新功能/缺陷时,基于master分支新建feature分支进行开发,
2. 发布时,基于master分支新建release分支,并将本次需要发布的feature分支合并入release分支,并基于此release分支发布
3. 将此release分支合并入master分支,并打tag标签 此操作发布前后进行都可以
4. 线上突然出现bug时,基于master分支新建release分支,基于此release分支新建feature分支,修复后再合并入release分支,重复2.3步操作.
5. 删除release分支,删除release分支关联的feature分支.

可以总结:
AoneFlow是通过release分支来关联feature分支来做分支管理的.