为什么一定要用专用工具标准,界定个递交规范化的文本文档

精英团队设计中，每一个人 git commit 的好习惯都不一样，如此不益于对升级日志的挑选，也能够防止朋友逃走后，发生 bug 后，不明白他在当时递交的日志到底是改了一个 bug 或是增加了一个作用，危害研发效率。

这个时候就需要使用 git commit 递交规范化的专用工具。为什么一定要用专用工具标准，界定个递交规范化的文本文档，让大家都自主遵循不就行了。这样的想法是美好的，实际却非常骨感美，在发散思维以后，头脑乏了，就可能忘掉公司制度的递交格式规范，习惯性用自己以前的递交习惯性，导致不必要的损失。

工具的使用进行规范，假如递交的格式有误，会给出相对应提示，也不能将 commit 开展递交，必须改动成恰当格式 commit 才可以安全提交到 git 库房。

配备 commitlint

commitlint 能够查验你 git commit 日志是否满足你配备的标准，这与标准 JavaScript 格式 Eslint 非常像。commitlint 是一个 npm 里的专用工具，因此需要在 npm init 复位以后项目才能进行。

当需要限定 git commit 项目下组装 commitlint ：

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

安装完成后，在工程目录下，新创建一个 .commitlintrc.json 文档，载入如下所示配备。

{ "extends": ["@commitlint/config-conventional"] }

extends 特性，意味着传承某一配备，上面继承 @commitlint/config-conventional 这一环境变量，把它当做默认配置文档就可以。

配备 husky

husky 是一个 git hook 专用工具，这个软件，还可以在 git 实行一些指令以前或是后再添加一些我们自己指令，学习过 vue 的，可以理解为是 git 的生命周期函数专用工具。

在目前新项目下组装 husky ：

npm install husky --save-dev

激话 hook ，执行完下边的指令后，会到新项目目录下建立出一个名称 .husk 我文件夹名称，里面是储放 hook 脚本制作的区域：

npx husky install

添加一个 hook，就和 vue 写了个 onMounted 方式相近，实行完了，.husky 文件夹名称下面会多加一个 commit-msg 的脚本文件：

npx husky add .husky/commit-msg  'npx --no -- commitlint --edit ${1}'

这一句指令大致意思便是，在实施 git commit -m 'xxx' 这一句指令时，应用 commitlint 查验 'xxx' 内容文件格式是否满足标准。不符标准，会终止 git commit -m 并导出报错。

这样一个基本的 git commit 文件格式校检就配备好啦，随意 git add 一些文档，随后实行 git commit -m 'xxx' 试一下实际效果，下面我直接放官方事例：

saltedfish@DESKTOP-623RCE5 MINGW64 /d/code/commitlint-demo (master)
$ git add .

saltedfish@DESKTOP-623RCE5 MINGW64 /d/code/commitlint-demo (master)
$ git commit -m "foo: this will fail"
⧗   input: foo: this will fail
✖   type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky - commit-msg hook exited with code 1 (error)

第 6 行一开始就是递交时的出错，先提醒你递交内容就是啥，随后对你说 type 也只能是中括号里的这些，你写的 foo 不符合规矩的。当把 foo 改为中括号里的 build 、chore 或 ci 等，就可以根据文件格式校检，并正常的递交 commit 。

saltedfish@DESKTOP-623RCE5 MINGW64 /d/code/commitlint-demo (master)
$ git commit -m "chore: lint on commitmsg"
[master (root-commit) af3dffd] chore: lint on commitmsg
 5 files changed, 2224 insertions( )
 create mode 100644 .commitlintrc.json
 create mode 100644 .gitignore
 create mode 100644 .husky/commit-msg
 create mode 100644 package-lock.json
 create mode 100644 package.json

commitlint 规则配置

有时，默认规则配置，不太适合我们自己的新项目应用，这时候，就可以使用有关配备特性，配备适宜我们自己递交标准。充分了解标准怎么配置以前，必须先了解一下递交 commit 格式一些定义。

type(scope?): subject
body?
footer?

默认设置标准中，配备了五种在日志所使用的具体内容，type 、scoped 、subject 、body 和 footer 。在其中，type 和 subject 是必填。

• type 是一些能够定制的递交种类，如新口作用（feat）、修补 Bug（fix）等，必须如何的格式能自己配备。
• subject 是简略叙述，实际上是平时大家 git commit -m 'xxx' 输入具体内容。

scope 我不怎么应用，大约是用来填好一些更改了什么文件的标识什么的，body 是详尽描述，便是 git commit -m 'xxx' 时，自动换行以后写一些详细说明，一般我就不会写，有 subject 我便够用。footer 这一我就不太用，实际写些啥都不太清楚。

掌握完定义后，就可以去开展我们自己的配备了，只介绍一些比较常用的配备，假如递交时，遇到一些不喜欢的配备，能看官方文档相匹配配备开展关掉。

一开始咱们就配备了一个 extends 特性，这就是传承他人提前准备好的配备。

{ "extends": ["@commitlint/config-conventional"] }

假如我们应该遮盖 extends 的规则配置，此刻，就需要使用 rules 特性，rules 接收到的一个对象（{}） ，key 相匹配标准名，value 相匹配标准，是一个长度为 3 的二维数组（[Level, Applicable, Value]） 。

• Level 有三个值，为 0 时，意味着关掉此标准，1 时，是警示，2 是不正确。
• Applicable 数值为 always | never ，为 never 时，翻转标准，应当是 Level 三个值反过来的意思吧。
• Value 我就不多说了，便是配备的值。

下面演试一个常用配备 rules['type-enum'] ，初始值是 ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'revert']，便是上面讲到的 type 只有填什么值。

{
  "extends": ["@commitlint/config-conventional"],
  "rules": {
    "type-enum": [
      2,
      "always",
      [
        "✨ 特色功能",
        "