前言
在团队协作开发时，每个人提交代码时都会写commit message。但是每个人都有自己的书写风格，提交代码之后message五花八门，十分不利于阅读和维护。
因此，我们需要制定统一标准，促使团队形成一致的代码提交风格，更好的提高工作效率，成为一名有追求的工程师。
本规范用于描述日常研发流程中关于GitLab上代码分支使用的规则，大家共同严格遵守规范，避免出现分支管理混乱现象，保证日常的发版上线工作顺利进行。
一、分支介绍
1.1 develop分支
开发者在接到需求之后主要从事开发工作的分支。初次创建develop时，需要从main分支拉取，保持开发时代码和线上最新的代码相同。develop分支是在开发时的最终分支，具有所有当前版本需要上线的所有功能。
1.2 release分支
当develop分支已经有了本次上线的所有代码的时候，并且以通过全部测试的时候，就可以从develop分支创建release分支了，release分支是为发布新的产品版本而设计的。
通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。
比如，此次1.0.0版本所有的功能版本都已经合并到了develop上，并且所有测试都已经通过了测试，那就创建新的release分支release/v1.0.0。切换到新分支，修改最新的版本号等，不允许大的更改。
1.3 main分支（原来为master）
与线上版本保持绝对一致。当release分支测试通过，表示代码随时能够发布时，会将代码merge到main分支，并且打上tag，至此，该版本封版，所有发现的bug均视为线上bug。线上出现的bug通过hotfix分支修复。
1.4 feature分支
用于开发功能的分支，必须从最新的develop分支代码拉取。分支命名基本上是private/姓名全拼/项目名。
不强制提交到远程仓库，可以本地创建。
1.5 hotfix分支
当线上出现bug需要紧急修复时，从当前main分支派生hotfix分支。
修改线上bug，修改完成后合并回develop和main分钟。
比如，在线上v1.0.0登录功能出现问题，我从main拉取代码创建新的分支hotfix/v1.0_login，修改完成后合并到main和develop上。
二、格式及说明
2.1 格式
提交前首先写明提交的内容，格式如下：
type: subject （注意：冒号后面有英文空格）
2.2 说明
( 1 ) type的选项，只允许使用下面几个标识：
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动，空格，格式化等等）
refactor：重构（既不是新增功能，也不是修改bug的代码变动）
perf: 性能（提高代码性能的改变）
test：增加测试或者修改测试
build: 影响构建系统或外部依赖项的更改（maven，gradle，npm等等）
ci: 对CI配置文件和脚本的更改
chore：对非src和test目录的修改
revert: 撤销上一次的 commit
( 2 ) subject: commit的简短描述，不超过50
三、提交、推送、合并流程
3.1 正常开发流程
本地创建个人分支作为feature分支，格式为：private/姓名全拼/项目名。
- 提交之前，首先拉取develop分支代码到本地个人分支；
- 提交并推送到远程个人分支上；
- 创建merge request，合并到develop分支上。
- 所有任务全部自测通过后，将develop分支merge到release分支上进行测试和验证，如果存在bug直接在该分支修改并合并到develop分支，如果验证通过则准备生产上线，
- 上线时将release代码合并到main分支，并打tag，tag名称为“v-版本号”，从main分支打包上线。
3.2 线上紧急bug修复流程：
- 当发现线上bug需要紧急修复时，需要以main分支为基准创建一个hotfix分支，分支名称为“hotfix-功能点-开发人员姓名全拼”；
- bug修复代码直接在新建的hotfix分支上提交，commit message需要填写任务描述与具体的开发内容。测试人员直接在hotfix分支测试。
- 测试通过后，开发人员同时请求合并到main分支和develop分支，合并请求消息同样需要复制任务描述以及具体的开发内容。
- 生产上线时将hotfix代码合并到main分支，并打tag，tag名称为“v-版本号”，从main分支打包上线。
