1、背景
在多人协作项目中，如果代码风格统一、代码提交信息的说明准确，那么在后期协作以及Bug处理时会更加方便。
因此，在本文章中，我会介绍怎么使用下面这个工具，在git push 代码之前检测commit messages：
commitlint
husky
2、先来介绍博主采用的commit规范
Commit message格式
<type>: <subject>
注意冒号后面有空格。
type
用于说明 commit 的类别，只允许使用下面7个标识。
Deat：新功能（feature）
Fix：修补bug
Docs：文档（documentation）
Style： 格式（不影响代码运行的变动）
Refactor：重构（即不是新增功能，也不是修改bug的代码变动）
Test：增加测试
Chore：构建过程或辅助工具的变动
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。
subject
subject是 commit 目的的简短描述，不超过50个字符，且结尾不加句号（.）。
3. 使用工具校验commit是否符合规范
3.1 全局安装
3.2 生成配置配件
这个文件在根目录下生成就可以了。
3.2 在commitlint.config.js制定提交message规范
上面我们就完成了commitlint的安装与提交规范的制定。检验commit message的最佳方式是结合git hook，所以需要配合Husky
3.4 husky介绍
husky继承了Git下所有的钩子，在触发钩子的时候，husky可以阻止不合法的commit,push等等。注意使用husky之前，必须先将代码放到git 仓库中，否则本地没有.git文件，就没有地方去继承钩子了。
安装成功后需要在项目下的package.json中配置
最后我们可以正常的git操作
git commit的时候会触发commlint。下面演示下不符合规范提交示例：
上面message不符合提交规范，所以会提示错误。
我们修改下type
commit成功。
3.5 husky的钩子
可以在package.json下面添加如下的钩子。
4、最后总结过程中遇到一些问题
- git commit后可能报错相关‘regenerator-runtime’模块找不到；解决方式：npm install regenerator-runtime –save。
- git commit -m “messge”,用双引号
[转载自]https://blog.csdn.net/y491887095/article/details/80594043
