Git规范
该规范主要从Git分支操作、以及Git的Commit Message格式两个方面进行解读。
首先、Git分支操作，其实有很多方案，不过在规定的时候，按照自己团队的情况进行实践。我经历的公司，有两种方案。
第一种方案是分为master分支、test分支、以及开发分支。
开发分支开发完，合并到test分支，test分支进行测试，测试完毕直接把test分支合并到master。
第二种方案是分为master分支、test分支、以及开发分支。
不同的是，我们的test分支仅仅是测试分支，因为可能有多个需求，都在test分支测试，但是由于上线日期不一样，所以上线的时候，直接把上线相关的开发分支合并到master。
下面介绍的git分支操作的第二种方案。
再次、说下Commit Message，由于我们开发的时候，多次进行commit，但是有些开发人员比较懒，随便写一些不规范的commit message，导致commit的可读性很低。
所以有必要针对commit，在项目的工程目录里面，做一些配置，规范团队行为。
GIT分支
1、GIT分支的定义
1、master分支
master代表一个稳定的可运行的版本，是我们的线上分支。
master分支的代码，才可以发布到ppe环境、production环境。
2、test分支
test分支代表我们的测试分支。
test分支的代码，会自动发布到测试环境。
3、feature分支
基本格式为：feature-date-name-需求功能（feature-20200322-mpb-xxx） feature分支，为每开发者的开发分支。
4、hotfix分支
基本格式为：hotfix-date-name-问题描述（hotfix-20200322-mpb-xxx） hotfix分支，为解决线上突发问题的分支。
2、GIT分支的操作
1、master分支
master分支，这个分支是一直存在的。
master合并的内容：就是本次上线的feature分支的需求。
master合并的时间：上线的时候。
master合并操作：只能由项目的owner进行操作，合并前需要自我review代码，要对风险负责。
2、test分支
test分支，只进行合并操作，合并的分支是当前要进行测试的feature分支（功能分支）。这个分支是一直存在的。
test分支的合并要求：提测什么需求，就合并相关分支的代码。test分支只做合并操作。
3、feature分支
feature分支的产生：从master上拉的一个新分支。
feature分支的销毁：上线完毕后，由分支owner进行销毁。
feature分支的合并到test，先在本地进行merge操作，解决冲突之后，再进行push。
4、hotfix分支
hotfix分支的产生：从master上拉的一个新分支。
hotfix分支的销毁：上线完毕后，由分支owner进行销毁。
hotfix分支的合并：如果需要经过测试，先合并到test分支，测试过后合并到master。如果属于紧急修复，响应时间作为第一参考标准的时候，经过自测，直接合并到master分支。
3、GIT分支操作流程
1、新的需求开发开始，先从master分支拉一个新的需求分支-feature分支，分支需要遵循命名规范。
2、开发完成，把feature分支的代码合并到test分支。
3、测试阶段开始，测试提出的bug，再feature分支上进行修复，修复完成持续合并到test分支。
4，测试完毕后，测试发提测邮件，需要发布ppe环境验证，使用feature分支发布ppe环境，并且保证再发布ppe环境之前，把master重新合并到feature分支。
5、ppe验收完成，需要正式上线，必须等产品确认才能对master执行合并操作（把feature分支的代码合并到master），再进行发布生产环境。
tips：hotfix分支的周期，同feature分支。区别点在于：hotfix在于线上问题的止损，出现问题，可能不会走测试流程。
Commit Message的格式
1、格式
Commit message的格式
每次提交，Commit message 都包含三个部分：Header，Body，Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
其中，Header是必须的，Body 和 Footer 可以省略。
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type用于说明 commit 的类别，只允许以下7个标识。
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
2、怎么做
针对以上的规范，如果人为进行控制，是非常麻烦的，社区有几个比较好用的包，可以尝试一下：commitizen、git-cz
1、git-cz
npm install -g git-cz
这样，在以后提交代码的时候，使用 git cz 来代替 git commit。
运行命令：git cz
2、commitlint
commitlint是对commit进行格式检查的一种工具。看是否符合上面说明的类似的message规范。
使用方式：
npm install --save-dev @commitlint/config-conventional @commitlint/cli
配置commitlint.config.js
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2,
'always',
[
'feat', // 新功能（feature）
'fix', // 修补bug
'docs', // 文档（documentation）
'style', // 格式（不影响代码运行的变动）
'refactor', // 重构（即不是新增功能，也不是修改bug的代码变动）
'test', // 增加测试
'chore' // 构建过程或辅助工具的变动
]
],
'header-max-length': [2, 'always', 72],
'type-empty': [2, 'never'],
},
};
然后配合ghooks进行如下配置：(package.json中)
"config": {
"ghooks": {
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}
这样，在每次 git commit 的时候，就会自动检验 Commit message 是否符合规范。
