良好的提交规范优势：

• 加快 Code Review 的流程
• 根据 Git Commit 的元数据生成更新日志
• 后续维护者可以知道相关代码被修改的原因

规范

一般不建议将多次修改放在一次提交中，尤其是一次半（第二个修改只完成了一部分）的情况

type(scope?): subject

• subject 指内容描述，要简明扼要，用简单的语句即可，必填。
• scope 指范围，可以是一个文件的地址，如 /lib/utils。也可以是某个功能点，不建议超过两个单词，选填。

• type 类型，必填：

  • build 代码构建编译相关
  • chore 改变构建流程、增加或更新依赖库等
  • ci 修改构建脚本类的修改
  • docs 修改文档，比如 README、CHANGELOG 等
  • feat 新增功能
  • fix 修复 Bug
  • perf 优化程序，比如提升性能和体验
  • refactor 代码重构，没有功能新增或问题修复（当然，也不包括问题新增
  • revert 回滚到上一个版本
  • style 代码格式化，例如修改空格、换行、缩进、逗号、冒号等
  • test 测试用例，包括单元测试、集成测试

项目配置

通过引入 commitlint 工具来辅助和约束，和相关检测规范：@commitlint/config-conventional：

npm i @commitlint/cli @commitlint/config-conventional -D

在项目根路径中增加 commitlint.config.js 配置文件：

module.exports = {
  extends: [
    '@commitlint/config-conventional'
  ]
}

使用 husky 工具在提交时，执行以上检查：