背景
Git每次提交代码都需要写commit message，否则就不允许提交。一般来说，commit message应该清晰明了，说明本次提交的目的，具体做了什么操作。但是在日常开发中，大家的commit message千奇百怪，中英文混合使用、fix bug等各种笼统的message司空见怪，这就导致后续代码维护成本特别大，有时自己都不知道自己的fix bug修改的是什么问题。基于以上这些问题，我们希望通过定制 git commit 规范，让规范更好的服务于质量，提高大家的研发效率。
规范建设
目前Angular规范是使用最广的写法，比较合理和系统化，并且有配套的工具（IDEA就有插件支持这种写法）。
commit message格式
Commit message 都包括三个部分：header，body 和 footer。
header 是必需的，body 和 footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
header
type 更改类型(必须)
用于说明git commit的类别，只允许使用下面的标识。
-
feat：新功能（feature）。
-
fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
-
fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
-
to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
-
-
docs：文档（documentation）。
-
style：格式（不影响代码运行的变动）。
-
refactor：重构（即不是新增功能，也不是修改bug的代码变动）。
-
perf：优化相关，比如提升性能、体验。
-
test：增加测试。
-
build: 构建依赖更改
-
ci: 更改 CI 配置文件或者脚本
-
chore：更改构建流程、或者增加依赖库、工具等
-
revert：回滚到上一个版本。
-
merge：代码合并。
-
sync：同步主线或分支的Bug。
scope 此次变更范围(可选)
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。如果你的修改影响了不止一个scope，你可以使用*代替。
scope 主要指的是代码的影响面。scope并没有要求强制，但团队可以按照自己的理解进行设计。通常由技术维度和业务维度两种划分方式。比如按照技术分为：controller、dto、service、dao等。但因为一个功能提交，会涉及到多个scope（都不喜欢非常细粒度的提交），所以按照技术维度分的情况比较少。
按照业务模块进行划分，也是比较不错的选择。比如分为user、order等划分，可以很容易看出是影响用户模块还是order模块
subject 简短描述(必须)
subject是commit目的的简短描述，不超过50个字符。技术文档的大标题、功能的概述
建议使用中文（感觉中国人用中文描述问题能更清楚一些）。
-
结尾不加句号或其他标点符号。
-
根据以上规范git commit message将是如下的格式：
fix(order): 修复了1分钱购买套餐的bug测试反馈可以1分钱买套餐，目前已经卖出了200单Closes #2677[skip ci]
body (可选)
body 详细描述
Body 部分是对本次 commit 的详细描述，可以分成多行。
-
第2行是空行
-
应该说明代码变动的动机，以及与以前行为的对比。
footer
changes 重大变更(可选)
即不兼容修改，指的是本次提交修改了不兼容之前版本的API或者环境变量
所有不兼容修改都必须在页脚中作为中断更改块提到，以BREAKING CHANGE:开头，后跟一个空格或者两个换行符，其余的信息就是对此次修改的描述，修改的理由和修改注释
BREAKING CHANGE: isolate scope bindings definition has changed andthe inject option for the directive controller injection was removed.To migrate the code follow the example below:Before:。。。。。。After:。。。。。。The removed `inject` wasn't generaly useful for directives so there should be no code using it.
closes 关闭问题(可选)
如果本次提交目的是修改issue的话，需要在页脚引用该issue
以关键字Closes开头，比如
Closes #234
如果修改了多个bug，以逗号隔开
Closes #123, #245, #992
skipCi(可选)
CI 全称 Continuous Integration，名为持续集成，传统的 CI 含义指的是代码仓库只要有代码变更（或者说有人想推代码入库），就会自动执行预先设计好的检查、防护流程，运行一系列构建、测试、部署等流程，并最终告知每一步的运行结果，确保人提交上来的代码没有问题后，才有机会将新代码合并到主干分支，而主干分支无论何时都一定是正确可运行的高质量版本，可以随时交付客户使用。
skip CI选项，跳过 CI 。一般的 CI 工具，都可以设置提交代码时自动触发编译。但你可以告诉它忽略本次提交。这可能是因为你提前预判到了一些构建风险，或者就是不想编译。
Revert
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert: 开头，后面跟着被撤销 Commit 的 Header。
revert: feat(pencil): add 'graphiteWidth' optionThis reverts commit 667ecc1654a317a13331b17617d973392f415f02.
规范 Git 提交信息工具
上面的内容比较多，记下来比较繁琐的，特别是有时候我们很难记住所有的 type 类型，IDEA 现在有一个插件，就是用来规范 git 提交模板的。
在 IDEA 的插件市场中安装 git commit message helper，直接搜索安装，然后重启 IDEA 即可。
在 VScode 可以安装插件 Git-commit-plugin For Vscode
案例：
点击提交后结果：
feat(dao): 加类加了xxxx
添加字段xxxx
删除xxxxBREAKING CHANGE: 添加xxxx2.0
删除xxx1.0Closes 1257[skip ci]
git commit 规范指南
Angular提交信息规范 - Git Guide
