1.1 缘由
重建一段代码的上下文是一种浪费。我们不能完全避免，我们只能努力尽最大可能去减少它。提交的信息就可以做到这一点，以至于一个提交信息可以表明一个开发者是不是一个好的合作者。
如果你对如何写好 git 提交信息没有仔细想过，那你很可能没有怎么使用过 git log 和相关工具。这里有一个恶性循环：因为提交的历史信息组织混乱而且前后矛盾，那后面的人也就不愿意花时间去使用和维护它。 又因为没有人去使用和维护它，提交的信息就会一直组织混乱和前后矛盾。
1.2 作用
- 提供更多的历史信息，方便快速浏览。
//下面的命令显示上次发布后的变动，每个commit占据一行。你只看行首，就知道某次 commit 的目的。
git log <last tag> HEAD --pretty=format:%s
- 可以过滤某些commit（比如文档改动），便于快速查找信息。
- 可以直接从commit生成Change log。
1.2 目的
统一团队git commit 团队日志标准，便于后续代码review和发布版本
2 规范
基于使用最广泛的angular日志规范
。
分为三部分：标题、内容、结尾，其中，==标题==是==必需==的，内容无需过多描述的话，正文内容部分可以省略。
不管是哪一个部分，任何。一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观
<类型>(范围): <主题>
// 空一行
<内容>
// 空一行
<Footer>
2.1 标题
- 标题部分只有一行，包括字段：类型 和 主题。
- 标题限制总字数在50个字符以内，以保证容易阅读。
feat: init LearnGit.git
I got a wrong-style git commit, so I init a .git for learning
how to write a git commit message in right way.
And the last line just write here for a simple test,
it's useless acturally.
2.1.1 类型
类型用于说明 commit 的类别，只允许使用下面7个标识。
- init：项目初始化（用于项目初始化或其他某种行为的开始描述，不影响代码）
- feat：新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- opt：优化和改善，比如弹窗进行确认提示等相关的，不会改动逻辑和具体功能等
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- other：用于难以分类的类别（不建议使用，但一些如删除不必要的文件，更新.ignore之类的可以使用）
2.1.2 范围
类型后面可以加上括号，括号内填写主要变动的范围，比如按功能模块分，某模块；或按项目三层架构模式分，分数据层、控制层之类的。
#：表示模块
- #market--> 表示 商城模块 （具体的模块开头字母小写，驼峰命名）
- #ALL --> 表示 所有模块 （特殊含义如ALL表所有，MOST表大部分，用大写字母表示）
- #MOST --> 表示 大部分模块
feat(#market): 新增添商城功能
2.1.3 主题
主题 是 commit 目的的简短描述，不超过50个字符。
- 第一个字母小写
- 以动词开头
- 结尾不加句号
2.2 内容
内容部分是对本次 commit 的详细描述，可以分成多行，正文在 72 个字符处换行。
使用正文解释是什么(what)和为什么(why)，而不是如何做，以及与以前行为的对比。
2.3 Footer
Footer 部分只用于两种情况：
-
不兼容变动
如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING
CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。 -
关闭 Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。
Closes #123, #245, #992
2.4 Revert
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。
revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
Body部分的格式是固定的，必须写成This reverts commit <hash>.，其中的hash是被撤销 commit 的 SHA 标识符。
3 工具
3.1 Commitizen
Commitizen是一个格式化commit message的工具。通过上面安装好的npm来安装：
npm install -g commitizen
而我们用的是Angular的commit message规范，那么就在我们项目的目录下输入以下命令：
commitizen init cz-conventional-changelog --save --save-exact
生成package.json文件，有时候这个文件名会错误，需要手动修改文件名。或者：
先在项目中添加一个空的package.json文件，然后再输入始化配置package.json文件命令：
npm init --yes然后输入：
commitizen init cz-conventional-changelog --save --save-exact
接下来在提交的时候，就用git cz替换git commit命令，会出现提交类型的选择，选择相应类型就好。
3.2 生成CHANGELOG
conventional-changelog就是生成 Change log 的工具。
运行下列命令：
$ npm install -g conventional-changelog
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -w
如果最后出现command not found，就要改用conventional-changelog-cli：
$ npm install -g conventional-changelog-cli
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -s
通过以上命令你就会发现在项目中多了个CHANGELOG.md文件，表示生成 Change log成功了。
