概述
为了后期协作以及处理Bug时会更加方便 引入commit规范,每次commit时，commitlint会用在git的hook回调中，最简单的就是和 husky一起使用；commitlint 检查您的提交消息是否符合常规提交格式。
使用commitlint可以便于通过允许人们探索更有条理的提交历史
使用
1、安装
需要先保证安装过依赖 husky
npm install --save-dev husky@4.2.5
安装@commitlint/config-conventional @commitlint/cli
npm install --save-dev @commitlint/config-conventional @commitlint/cli
2、配置
生成配置文件commitlint.config.js，当然也可以是 .commitlintrc.js
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js
在husky的配置加入CommitlIint配置，v1.0.1版本以后为HUSKY_GIT_PARAMS，v0.14.3为GIT_PARAMS
"husky": {
"hooks": {
"commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
}
},
3、小测试
可以看到格式不正确，报错
4、定制提交规范
提交格式：: （注意冒号后面有空格）
常用的type类别
-
upd：更新某功能（不是 feat, 不是 fix）
-
feat：新功能（feature）
-
fix：修补bug
-
docs：文档（documentation）
-
style： 格式（不影响代码运行的变动）
-
refactor：重构（不是新增功能，也不是修改bug的代码变动）
-
test：增加测试
-
chore：构建过程或辅助工具的变动
示例：
git commit -m 'feat: 增加了XXX功能'
git commit -m 'bug: 修复了xxx功能'
subject:是commit目的的简短描述，可以做一些配置，比如最大长度限制。
可以看到触发了package.json中配置的husky中的pre-commit钩子，执行了npm version
然后触发了commit-msg中配置的commitlint的检查，这里的bug并没有加到type中，所以报错
现在，我们在配置文件commitlint.config.js中写一些rules，把bug的type写进去
关于rule的配置说明
:：rule由name和配置数组组成，如：'name:[0, 'always', 72]'，数组中第一位为level，可选0,1,2，0为disable，1为warning，2为error，0表示禁用规则，第二位为应用与否，可选always|never，never表示反转规则，第三位该rule的值。
这里先使用错误的提交方式：
git commit -m "hello"
可以看到这里报错了
然后使用正确的提交方式
git commit -m "bug: 修复了一点点bug"
可以看到commit成功
体会
commitlint可以帮助我们在commit的时候进行检查，对我们的提交更加规范化，有利于养成规范化的提交习惯
