大厂前端git提交规范及commitizen、husky、commitlint、lint-staged安装配置

一、约定式提交规范

在项目开发中，通常都会通过git来管理项目。

当我们执行 git commit -m "描述信息" 的时候，我们知道此时必须添加一个描述信息。但是中华文字博大精深，不同的人去填写描述信息的时候，都会根据自己的理解来进行描述。

而很多人的描述 “天马行空” ，这样就会导致别人在看你的提交记录时，看不懂你说的什么意思？不知道你当前的这次提交到底做了什么事情？会不会存在潜在的风险？

对于git提交规范来说，不同的团队可能会有不同的标准，那么咱们今天就以目前使用较多的《Angular团队规范》延伸出的《Conventional Commits specification（约定式提交）》为例，来为大家详解git提交规范。

约定式提交规范要求如下：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

--------  翻译 -------------
    
<类型>[可选 范围]: <描述>

[可选 正文]

[可选 脚注]

其中 `<type>` 类型，必须是一个可选的值，比如：

1. 新功能：`feat`

2. 修复：`fix`

3. 文档变更：`docs`

4. ....

也就是说，如果要按照 约定式提交规范 来去做的化，那么你的一次提交描述应该式这个样子的：

我想大家看到这样的一个提交描述之后，心里的感觉应该和我一样是崩溃的！要是每次都这么写，写到猴年马月了！

如果你有这样的困惑，那么“恭喜你”，接下来我们将一起解决这个问题！

二、Commitizen助你规范化提交代码

经过了很多人的冥思苦想，就出现了一种叫做git提交规范化工具的东西，而我们要学习的commitizen就是其中的佼佼者！

commitizen仓库名为cz-cli ，它提供了一个git cz的指令用于代替git commit，简单一句话介绍它：

当你使用 commitizen 进行代码提交（git commit）时，commitizen 会提交你在提交时填写所有必需的提交字段！

下面我们就来安装并且使用一下commitizen，使用完成之后你自然就明白了这句话的意思！

1）全局安装commitizen

npm install -g commitizen

2）安装并配置cz-customizable插件

使用npm下载cz-customizable

npm install cz-customizable --save-dev

添加以下配置到package.json中

"config": {
  "commitizen": {
    "path": "node_modules/cz-customizable"
  }
}

3）项目根目录下创建 .cz-config.js 自定义提示文件

module.exports = {
  // 可选类型
  types: [
    { value: 'feat', name: 'feat:     新功能' },
    { value: 'fix', name: 'fix:      修复' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式(不影响代码运行的变动)' },
    {
      value: 'refactor',
      name: 'refactor: 重构(既不是增加feature，也不是修复bug)'
    },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     增加测试' },
    { value: 'chore', name: 'chore:    构建过程或辅助工具的变动' },
    { value: 'revert', name: 'revert:   回退' },
    { value: 'build', name: 'build:    打包' }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交？(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer'],
  // subject文字长度默认是72
  subjectLimit: 72
}

使用 git cz 代替 git commit 即可看到提示内容。

但是当前依然存在着一个问题，那就是我们必须要通过 git cz 指令才可以完成规范化提交！

那么如果有马虎的同事，它们忘记了使用 git cz 指令，直接就提交了怎么办呢？

下面我们使用Git Hooks来限制这种情况的出现。

什么是Git Hooks？

Git Hooks也叫git 钩子或git 回调方法，作用是git在执行某个事件之前或之后进行一些其他额外的操作。

而我们所期望的阻止不合规的提交消息，那么就需要使用到hooks的钩子函数。

整体的hooks非常多，详细的hooks介绍可点击这里查看，但是我们其中用的比较多的其实只有两个：

简单来说这两个钩子：

1）commit-msg：可以用来规范化标准格式，并且可以按需指定是否要拒绝本次提交。

2）pre-commit：会在提交前被调用，并且可以按需指定是否要拒绝本次提交。

而我们接下来要做的关键，就在这两个钩子上面。

三、使用 husky + commitlint 检查提交描述是否符合规范要求

我们了解了 git hooks 的概念，那么接下来我们就使用 git hooks 来去校验我们的提交信息。

要完成这么个目标，那么我们需要使用两个工具：

commitlint：用于检查提交信息。

husky：是 git hooks 工具。

注意：npm 需要在 7.x 以上版本！

那么下面我们分别来去安装一下这两个工具：

commitlint安装与配置：

1）安装依赖

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

2）创建 commitlint.config.js 文件

echo "export default {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

3）打开 commitlint.config.js，增加配置项（ config-conventional 默认配置点击可查看）：

module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
      2,
      'always',
      [
        'feat', // 新功能 feature
        'fix', // 修复 bug
        'docs', // 文档注释
        'style', // 代码格式(不影响代码运行的变动)
        'refactor', // 重构(既不增加新功能，也不是修复bug)
        'perf', // 性能优化
        'test', // 增加测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'build' // 打包
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

husky安装与配置：

1）安装依赖

npm install --save-dev husky

2）启动 hooks， 生成 .husky 文件夹

npx husky install

3）在 package.json 中生成 prepare 指令

npm set-script prepare "husky install"

4）执行 prepare 指令

npm run prepare

5）添加 commitlint 的 hook 到 husky 中，并指令在 commit-msg 的 hooks 下执行 npx --no-install commitlint --edit "$1" 指令

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

6）此时的 .husky 的文件结构

那么至此，我们就已经可以处理好了强制规范化的提交要求，到现在不符合规范的提交信息，将不可再被提交！

四、通过 pre-commit 检测提交时代码规范

现在我们还缺少一个规范化的处理 ，那就是代码格式提交规范处理！

在 ESLint 与 Prettier 配合解决代码格式问题的文章中，我们讲解了如何处理本地代码格式问题。

但是这样的一个格式处理问题，他只能够在本地进行处理，并且我们还需要手动在 VSCode 中配置自动保存才可以。那么这样就会存在一个问题，要是有人忘记配置这个东西了怎么办呢？他把代码写的乱七八糟的直接就提交了怎么办呢？

所以我们就需要有一种方式来规避这种风险。

那么想要完成这么一个操作就需要使用 husky 配合 eslint 才可以实现。

通过 pre-commit 检测提交时代码规范：

1）添加 pre-commit 的 hook

npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src"

2）该操作会生成对应文件 pre-commit

此后不符合 ESLint 校验规则的代码，执行提交操作会发现，抛出一系列的错误，代码无法提交。想要提交代码，必须处理完成所有的错误信息。

五、lint-staged 自动修复格式错误

通过 pre-commit 处理了检测代码的提交规范问题，当我们进行代码提交时，会检测所有的代码格式规范 。

但是这样会存在两个问题：

1）我们只修改了个别的文件，没有必要检测所有的文件代码格式。

2）它只能给我们提示出对应的错误，我们还需要手动的进行代码修改。

那么想要处理这两个问题，就需要使用另外一个插件 lint-staged ！

lint-staged可以让你当前的代码检查只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送。

lint-staged 安装与配置：

1）安装依赖

npm install --save-dev lint-staged

2）修改 package.json 配置

"lint-staged": {
  "src/**/*.{js,vue}": [
    "eslint --fix",
    "git add"
  ]
}

如上配置，每次它只会在你本地 commit 之前，校验你提交的内容是否符合你本地配置的 eslint 规则，校验会出现两种结果：

a）如果符合规则：则会提交成功。

b）如果不符合规则：它会自动执行 eslint --fix 尝试帮你自动修复，如果修复成功则会帮你把修复好的代码提交，如果失败，则会提示你错误，让你修好这个错误之后才能允许你提交代码。

3）修改 .husky/pre-commit 文件

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

此后再执行提交代码，发现不符合 ESlint 的内容，被自动修复。

总结：

对于 git提交规范 而言我们使用了 husky 来监测 Git Hooks 钩子，并且通过以下插件完成了对应的配置：

1）约定式提交规范

2）commitizen：git 提交规范化工具

3）commitlint：用于检查提交信息

4）pre-commit：git hooks 钩子

5）lint-staged：只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送。