git分支管理规范

基本流程

1. 迭代启动

● 负责人从master拉出release分支，并将开发环境分支切换为该分支。

2. 开发阶段

● 开发人员从master拉取分支，建立自己的feature分支。
● 开发人员在各自负责的需求分支feature上开发代码，开发完成后向release分支发起merge request，并交由负责人审核后合并。

3. 测试阶段

● 负责人将测试环境分支切换为当前release分支。
● 开发人员根据缺陷ID从当前release分支拉取修复分支feature，缺陷修复完成后向release分支发起merge request，并交由负责人审核后合并。然后由测试人员回归测试。
4.发布阶段
● 负责人将生产环境切换为当前release分支，并用该分支代码进行发布。
● 发布完成后，将当前release分支代码合并回master分支以及其他未发布的release分支。

分支介绍

1.master分支

master分支为主分支，用于存放对外发布的版本，保持和生产一致。

2.release分支

release分支为迭代分支，基于master分支按照正确的命名规则创建的一个迭代分支，当版本需要上线时，需要合并到master分支。

3.feature分支

新需求开发分支，由开发人员从master分支上来取代码后，按照正确的命名规则自行创建。

4.hotfix分支

当生产环境出现紧急问题需要临时修复时，需要使用该分支，待问题修复完成并验证通过后，合并到master，并同步到release分支。

命名规范

基本要求

● 命名中允许的字符: 小写英文字符、数字、单斜杠(/)、下划线(_)。
● 单斜杠只能接在分支类型后，如release/xxx、feature/xxx、hotfix/xxx。
1.master分支
● 不加任何后缀。
2.release分支/hotfix分支
● 按照预定迭代发布日期yyyyMMdd命名，例如release/20220101。
● 如果同一日期有多个发布，则用下划线+递增数字作为后缀，例如release/20220101_2。
● 如果迭代上线日期变更，但迭代对应的需求没有减少，依然可以使用原迭代名。
3.feature分支
● 按照需求/缺陷ID来命名，例如feature/1234，feature/bugfix1234。
● 如果多个人开发同一个需求，则在分支名后加姓名拼音，例如feature/1234_zhangsan。
● 对于小型项目，按照迭代分支+下划线+姓名拼音来命名，例如feature/20220101_zhangsan。

红线

● 禁止向master、release、hotfix直接push代码，必须走merge request。
● 提交commit message需要写清楚本次提交代码的用途。
● 禁止存在除master、release、hotfix、feature开头外的其他命名分支。