commitlint配置在多人协作的背景下，git 仓库和 workflow 的作用很重要。而对于 commit 提交的

一、安装

首先需要先安装 husky

npm install --save-dev husky

然后安装@commitlint/config-conventional @commitlint/cli

npm install --save-dev @commitlint/config-conventional @commitlint/cli

二、配置

配置与 husky 的版本有关，此处主要是旧版本，比如4.2.5，新版本配置变化较大，可参考 husky官方文档

生成配置文件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": {
    "pre-commit": "npm run test", // 可以在commit前执行自定义的命令
    "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS" // 校验commit时添加的描述信息是否符合配置的commit规范
  }
}

三、提交规范

3.1 提交格式

git commit -m <type>[optional scope]: <description>

3.1.1 常用type类别

type ：用于表明我们这次提交的改动类型，是新增了功能？还是修改了测试代码？又或者是更新了文档？总结以下 11 种类型：

build：主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
ci：主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
docs：文档更新
feat：新增功能
fix：bug 修复
perf：性能优化
refactor：重构代码(既没有新增功能，也没有修复 bug)
style：不影响程序逻辑的代码修改(修改空白字符，补全缺失的分号等)
test：新增测试用例或是更新现有测试
revert：回滚某个更早之前的提交
chore：不属于以上类型的其他类型(日常事务)

optional scope：一个可选的修改范围。用于标识此次提交主要涉及到代码中哪个模块。

description：一句话描述此次提交的主要内容，做到言简意赅。

3.1.2 示例

git commit -m 'feat: 增加 xxx 功能'
git commit -m 'bug: 修复 xxx 功能'

3.2 commitlint.config.js文件配置

rule配置说明:：rule由name和配置数组组成，如：'name:[0, 'always', 72]'，数组中第一位为level，可选0,1,2，0为disable，1为warning，2为error，第二位为应用与否，可选always|never，第三位该rule的值。具体配置例子如下：

module.exports = {
  extends: [
      '@commitlint/config-conventional'
  ],
  rules: {
    'type-enum': [2, 'always', [
      'build', 'ci', 'perf', 'feat', 'fix', 'refactor', 'docs', 'chore', 'style', 'revert', 'test'
    ]],
    'type-case': [0],
    'type-empty': [0],
    'scope-empty': [0],
    'scope-case': [0],
    'subject-full-stop': [0],
    'subject-case': [0, 'never'],
    'header-max-length': [0, 'always', 72]
  }
}

此处只是部分常用配置，如需要详细配置，可以参考commitlint官网

commitlint配置