一、现状分析
目前我们的项目在commit时基本上五花八门，各领风骚。虽然不如网上的那些恶搞commit记录，但是这一现象严重影响我们在阅读记录和查找bug原因时的效率。
我们可以感受下：
可以对比看看同样按照规范式提交的项目的commit记录
其实已经越来越多的人开始意识到规范化提交的重要性，据我在公司实地采访了一圈，前端团队早已经开始约定式提交，这也可能是因为目前社区中主流的提交规范都是由Angular提交准则形成
为了提高开发效率，减少在处理问题时耗费的时间，推荐大家在写完代码，提交时能够使用以下规范：
· 规范化提交(不一定是文中提到的方式,但无论哪种方式，要做到统一、简明)
· 一处变更一次commit(谨防多处、多次修改堆积成一次commit提交，这对后期bug分析将是灾难)
约定式提交：每次使用git commit 的时候都需要写commit message,如果message的 style是按照固定的模版格式书写，对于后期的维护和编写changelog都有巨大的好处。
而且现在的很多自动生成changelog的工具，都是建立在约定式提交的基础之上。
优点
可读性好，清晰，不必深入看代码即可了解当前commit的作用。
为 Code Reviewing做准备
方便跟踪工程历史
让其他的开发者在运行 git blame 的时候想跪谢
提高项目的整体质量，提高个人工程素质
提交说明的结构如下所示：
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
其中，<类型>是为了向类库使用者表明其意图，其可选值为：
feat: 表示新增了一个功能
fix: 表示修复了一个 bug
docs: 表示只修改了文档
style: 表示修改格式、书写错误、空格等不影响代码逻辑的操作
refactor: 表示修改的代码不是新增功能也不是修改 bug，比如代码重构
perf: 表示修改了提升性能的代码
test: 表示修改了测试代码
build: 表示修改了编译配置文件
chore: 无 src 或 test 的操作
revert: 回滚操作
[可选的作用域]: 是为了描述 此次 commit 影响的范围，比如: route, component, utils, build, api, website, docs
<描述>: 此次提交的简短描述
[可选的正文]: 此次提交的详细描述，描述为什么修改，做了什么样的修改，以及开发的思路等等，输入 n 换行
[可选的页脚]: 主要写下面2种
Breaking changes: 在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交，表示引入了破坏性变更（这和语义化版本中的 MAJOR 相对应）。
Closed issues: 罗列此次提交修复的 bug，如 fixes issue #110
二、commitlint
此工具的好处：支持钩子，也就是说不管用命令行还是可视化的“乌龟”提交代码都可以通过配置约定规则，做出标准的 commit message
URL:https://commitlint.js.org/#/guides-local-setup?id=install-commitlint
使用步骤：
1、 安装commitlint 并配置config
进入项目目录 输入 npm init 用于创建package.json文件，[很重要]
然后
npm install --save-dev @commitlint/{cli,config-conventional}
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.
2、 安装钩子:husky
npm install --save-dev husky
将下面的配置复制到 package.json当中
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
3、 测试 commitlint
npx commitlint --from HEAD~1 --to HEAD –verbose
出现如下图 代表成功
4、 测试钩子husky
出现如下图 代表成功
以上说明 可以使用正常的git commit 命令即可进行约束验证，如果不合格会给出提示，并无法commit