一、前言
为什么要对 commit msg 进行规范化？
在团队合作开发时，当你遇到需要上线分支中的一部分功能，想要 cherry-pick 的时候，就会很难受，commit msg清一色都是update xxx，也不知道要把哪些 commit 找出来。同样，其他人在阅读你的提交记录时也会非常头疼，不知道到底修改了什么。这时候就需要对提交信息进行规范化处理了。
如果 git commit 的描述信息精准，在后期维护和 Bug 处理时会变得有据可查，项目开发周期内还可以根据规范的提交信息快速生成开发日志，从而方便我们追踪项目和把控进度。
对于 git 的提交规范，不同的团队可能有不同的标准，目前比较流行的是 Angular 规范。
二、commit msg 提交规范
每次提交，Commit msg 都包括三个部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
- Header（必需）：只有一行，包括三个字段：
type（必需）、scope（可选）和subject（必需）。
（1） type
type用于说明 commit 的类别，有如下几种。
- feat：添加新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- style：格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
（2）scope
scope 用于指定本次 commit 影响的范围。scope 依据项目而定，例如在业务项目中可以依据菜单或者功能模块划分，如果是组件库开发，则可以依据组件划分。
（3）subject
subject是 commit 目的的简短描述，不超过50个字符,通常遵循以下几个规范：
- 以动词开头，使用第一人称现在时，比如`change`，而不是`changed`或`changes`
- 第一个字母小写
- 结尾不加句号（`.`）
- Body（可选）：是对本次 commit 的详细描述，可以分成多行。
应该说明代码变动的动机，以及与以前行为的对比。
- Footer（可选）：是对不兼容变动和关联的issue进行描述。
如果本次提交的代码是突破性的变更或关闭缺陷，则 Footer 必需，否则可以省略。
（1） 突破性的变更
当前代码与上一个版本有突破性改变，则 Footer 以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动的理由。
（2） 关闭缺陷
如果当前提交是针对特定的 issue，那么可以在 Footer 部分填写需要关闭的单个 issue 或一系列 issues。
三、Commitizen 实现规范提交
安装 Commitizen
npm install -g commitizen
然后，运行下面的命令，使其支持 Angular 的 Commit message 格式。
commitizen init cz-conventional-changelog --save --save-exact
以后，凡是用到git commit命令，一律改为使用git cz。就会出现如下选项，用来生成符合格式的 Commit message。
四、生成 change log
如果你的所有 Commit 都符合 Angular 格式，那么发布新版本时， Change log 就可以用脚本自动生成,输入命令安装：
npm i conventional-changelog-cli --save-dev
配置 package.json
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
上面 changelog 命令不会覆盖以前的 CHANGELOG，只会在 CHANGELOG.md 的头部加上自从上次发布以来的变动。
npm run changelog
会生成一个 CHANGELOG.md 文件
