用Commitizen实现优雅规范的commit风格
做项目开发有一段时间了，作为leader肯定是经常给团队成员讲，commit信息不能乱写，要突出这次提交修改了什么，同时最好一个功能一个commit，不要全混在一起。然而，执行中大家往往习惯写出这些commit：
修复BUG（到底修复什么BUG？）
调整了xx业务的逻辑（到底调整了什么逻辑？）
xxx业务改了啥啥啥；yyy业务改了啥啥啥....（冗长的描述，明明可以分开commit的）
...
说实话，我自己写代码都真的在commit规范上做的很差。很多时候，除了写出上面列出的反例，对于个人项目甚至都懒得搞git管理。
究其原因，其实还是因为懒。commit信息要写好，还是需要一些心智成本的，有时候代码呼呼写，实在是不愿意停下来想想给刚才写好的东西commit存个档，直接接着下一个业务继续开撸了。
最近筹划做个自己的开源项目，想要从各种方面好好规范自己的编程习惯，在commit这块上必然是少不了，因此决定好好学学Angular提交规范。
# Angular提交规范
首先来快速了解一下在Angular风格下，要怎么编写commit message。
开始之前普及一个热知识，git中commit message是允许多行书写的。
Angular风格规定commit message必须遵循如下格式：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
也就是三大块内容：首行（必须），详情（可选），脚注（可选）。
# 首行
首行文本的作用是简明扼要地描述这个commit到底干了什么事。它由三个部分组成：类型type（必须），范围scope（可选），描述subject（必须）
# 类型
有如下几种类型可选：
build：影响构建系统、外部依赖的改动
ci：更改自动集成（CI）相关文件、脚本的改动
docs：文档的改动
feat：添加了新的功能
fix：修复了BUG
pref：性能优化类型的改动
refator：代码重构，这种改动理应对程序原逻辑无影响
test：对测试代码的改动
# 范围
描述这次更改改了啥地方，比如改了某个文件、某个函数...
# 描述
简明扼要地描述这次更改，不要写太长。
# 详情
首行后面空一行，再跟着可以写详情。详情中，可以写这个为啥你会进行这个更改、这个更改会带来的变化和与之前逻辑的变化。如果是比较简单的更改，这个部分可以省略。
# 脚注
详情后面空一行，再跟着可以写脚注。脚注中，如果更改是重大的，不向后兼容（Breaking Changes）的，就应该写在这里，格式应该是以BREAKING CHANGE:开头，紧跟一个空格或者再空一行，再详细描述这个重大更新带来的影响。
另外，脚注也可以用来标记这个更新对应的issues。
还有一些英语语法上的规范，这里就不列出了，让我们来试几个例子：
我要修改readme文件，那我的commit应该是：
docs(readme):readme加上了作者名字我加了一个新功能，那我的commit应该是：
feat(user):添加用户注销功能 用户注销后，数据库数据不会删除，仅做注销标记，后续对用户进行的其他查询应对此进行过滤处理我修复了热心群众提的1234号issue bug，那我的commit应该是：
fix(user):修复用户注销失败的BUG 之前注销失败是因为没有考虑用户email空的情况，现在就算用户没有email也可以注销成功 Fixes #1234
可以看出，规范化的commit格式可以让项目git提交记录看起来和读书一样优雅美观，看一眼首行就可以知道这次更改的类型、干了啥，点开看看详情可以快速掌握这次更改需要知道的其他信息。
不过，规范学起来不太容易，一开始需要记忆定义的这些类型名字和他们对应的意义，有些不方便，能不能更加优雅一些？
说起这个，很多程序员的DNA应该就动了，优（偷）雅（懒）应该是大家的共同追求吧：）
我们可以借助commitizen来解决这个问题。commitizen为上述流程提供了交互式的执行方式，不需要记忆规范内容，只需要按它的提示选择、编写就行。
# commitizen
首先来安装commitizen。
设置镜像解千愁：
npm config set registry https://registry.npmmirror.com
全局安装commitizen：
npm install -g commitizen
然后初始化当前项目，以适配commitizen的配置：
commitizen init cz-conventional-changelog --save-dev --save-exact
完成后，执行
cz
即可进入commitizen交互式环境，一步步选择、编写规范的commit message。
执行前，要先把待提交的代码加入git stage，如果跟着commitizen写完了message但是stage是空的，那你就得重写一遍message了！最简单的把所有修改过的文件加入stage的命令：
git add .
这是我摸索完，体验的效果，感觉就是非常优雅！
