Git Flow流程规范

一、Git Flow流程

将测试和生产的工作流分开，避免产生一堆无效分支和标签 严格按照git flow流程进行分支的合并. 详细参照《POCSTARS GIT仓库管理和使用规范》

以下是git flow 流程的示例:

1、master 【生产分支，永久保留发布版本】

生产基准分支，始终与生产环境的代码保持一致

2、develop【开发分支，永久保留开发版本】

开发基准分支，在没有多版本同时存在的情况下与master保持一致

3、feature【功能分支或者新特性分支】

只能从develop分支上创建feature分支，分支命名以功能描述命名，例：feature/add-new-feature（develop -> feature），开发完成后合并到develop分支并且删除feature分支

4、release【发布分支】

当前版本的所有功能分支都合并到develop后，从develop分支上创建release分支，以当前版本号命名，例：release/v1.0.2 ，测试完成后封版，完成上线后合并release分支到master与develop并且打tag

5、hotfix【修复分支】

生产问题修复分支，只能从master上分支创建，以修复的发布版本号为基准命名，例：修复v1.0.2版本的问题，v1.0.2.1，测试完成并且发布成功后合并到master与develop，如果有存在release版本也需要合并过去。

二、版本命名规则

1、版本号

• 产品需求版本号，与开发（前、后端）代码版本号解耦
• 业务系统各自版本号相互独立，各自递增
• 上线版本号、提交缺陷版本号，与产品版本号保持一致（缺陷补丁版本除外，统一版本号第三位递增）
• 开发提测邮件中，标明代码版本号与上线版本号（即产品版本号）

当本次提测不涉及具体需求版本（补丁版本，公共基础服务版本），则上线版本号与开发代码版本号一致（测试到禅道上新增该版本号，用于管理缺陷）

2、命名规则

• 功能（feature）分支 ：采用 feature/* 的形式命名，这里的 * 根据需求取关键词，如 feature/add-login 。
• 发布（release）分支 ： 采用 release/* 的形式命名，这里的 * 根据上线版本号，如 release/v1.0.0
• 修补bug（hotfix）分支 ： 采用 hotfix/* 的形式命名，这里的 根据上线版本号，如 hotfix/v1.0.0.1 。
• 标签 （tags）：直接用上线版本号命名，如 v1.0.0 、v1.0.0.1。

PS：版本号说明，第一位有较大的变动更新,第二位时间跨度较长或者迭代时间超过三个月更新，第三位每次迭代都要更新，每次递增1，紧急版本与修复版本第四位。