commit介绍
我们都知道，Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交，这其实就是规范。
$ git commit -m "commit message"
- 上面代码的 -m 参数，就是用来指定 commit message 的。
- 如果一行不够，可以只执行git commit，就会跳出文本编辑器，让你写多行。
- 一般来说，commit message 应该清晰明了，说明本次提交的目的。而且多人协作的时候，有问题也方便查看提交日志。
- 目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。如下图：
commit剖析
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
<header>
<body>
<footer>
其中，Header 是必需的，Body 和 Footer 可以省略。
不管是哪一个部分，任何一行都不要有太多字符。这是为了避免自动换行影响美观。
Header
Header部分只有一行，包括三个字段：type（必填）、scope（影响范围，选填）和subject（必填）。
<type>(<scope>): <subject>
type
type 用于说明 commit 的类别，只允许使用下面7个标识（或者用对应的 emoji 表情，在前边再加一个: 就会显示了）。
| 名称 | 说明 | 图标 |
|---|---|---|
| feat | 新功能 | ✨ |
| fix | 修补bug | 🚑 |
| docs | 修改文档 | 📚 |
| style | 格式化代码结构，没有逻辑上的代码修改。）（如空白，格式、缺少分号等) | 🎨 |
| refactor | 即不是新增功能，也不是修改bug的代码变动，比如重命名变量） | 🚜 |
| test | 增加测试代码，单元测试一类的，没有生产代码的变更） | 🔬 |
| build | 影响构建系统或外部依赖的更改(如: gulp、 broccoli、 npm) | |
| ci | 对Cl配置文件和脚本的更改（如：Travis、Circle、Browserstack、Saucelabs） | |
| chore | 不修改src或测试文件的其他更改 | |
| revert | 撤销上一次的commit提交 |
revert说明： 如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。
revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
scope
scope 用于定义 type 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject
subject是 commit 目的的简短描述，不超过50个字符。
Body
Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符。 注意：应该说明代码变动的动机，以及与以前行为的对比。 无重大变更，一般不写。
Footer
Footer 部分只用于两种情况
-
不兼容变动：如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
-
关闭 Issue：如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。
Closes #234
Closes #123, #245, #992
这么多规范有什么用吗，如果项目中只有两三个人开发，其实也不需要严格的规范，只要把提交内容写清楚就行，但是大型项目，开发人员较多，规范提交还是有必要的
格式化Commit message的优点
提供更多的历史信息，方便快速浏览
比如，下面的命令显示上次发布后的变动，每个 commit 占据一行。你只看行首，就知道某次 commit 的目的。
$ git log <last tag> HEAD --pretty=format:%s
可以过滤某些commit（比如文档改动），便于快速查找信息
比如，下面的命令仅仅显示本次发布新增加的功能
$ git log <last release> HEAD --grep feature
可以直接从 commit 生成 Change log（Change Log 是发布新版本时，用来说明与上一个版本差异的文档）
