git husky和git commit 提交规范

917号先生
175 阅读8分钟

工欲善其事，必先利其器

对于一些大型的企业级项目而言，通常情况下我们都是需要一个团队来进行开发的。而又因为团队人员对技术理解上的参差不齐，所以就会导致出现一种情况，那就是《一个项目无法具备统一的编程规范，导致项目的代码像多个不同材质的补丁拼接起来一样》

大厂编程规范一：代码检测工具 ESLint 你了解多少？

在我们去创建项目的时候，脚手架工具已经帮助我们安装了 ESLint 代码检测工具。

对于 ESLint 的大名，同学们或多或少的应该都听说过，只不过有些同学可能了解的多一些，有些同学了解的少一些。

那么本小节我们就先来聊一下，这个赫赫有名的代码检测工具 ESLint

首先 ESLint 是 2013年6月 创建的一个开源项目，它的目标非常简单，只有一个，那就是 提供一个插件化的 javascript 代码检测工具 ，说白了就是做 代码格式检测使用的

在咱们当前的项目中，包含一个 .eslintrc.js 文件，这个文件就是 eslint 的配置文件。

随着大家对代码格式的规范性越来越重视，eslint 也逐渐被更多的人所接收，同时也有很多大厂在原有的 eslint 规则基础之上进行了一些延伸。

我们在创建项目时，就进行过这样的选择：

? Pick a linter / formatter config: 
  ESLint with error prevention only // 仅包含错误的 ESLint
  ESLint + Airbnb config // Airbnb 的 ESLint 延伸规则
  ESLint + Standard config // 标准的 ESLint 规则

我们当前选择了 标准的 ESLint 规则 ，那么接下来我们就在该规则之下，看一看 ESLint 它的一些配置都有什么？

打开项目中的 .eslintrc.js 文件

// ESLint 配置文件遵循 commonJS 的导出规则，所导出的对象就是 ESLint 的配置对象
// 文档：https://eslint.bootcss.com/docs/user-guide/configuring
module.exports = {
  // 表示当前目录即为根目录，ESLint 规则将被限制到该目录下
  root: true,
  // env 表示启用 ESLint 检测的环境
  env: {
    // 在 node 环境下启动 ESLint 检测
    node: true
  },
  // ESLint 中基础配置需要继承的配置
  extends: ["plugin:vue/vue3-essential", "@vue/standard"],
  // 解析器
  parserOptions: {
    parser: "babel-eslint"
  },
  // 需要修改的启用规则及其各自的错误级别
  /**
   * 错误级别分为三种：
   * "off" 或 0 - 关闭规则
   * "warn" 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)
   * "error" 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)
   */
  rules: {
    "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off"
  }
};
​

那么到这里咱们已经大致的了解了.eslintrc.js 文件，基于 ESLint 如果我们出现不符合规范的代码格式时，那么就会得到一个对应的错误。

比如：

我们可以把 Home.vue 中的 name 属性值，由单引号改为双引号

此时，只要我们一保存代码，那么就会得到一个对应的错误

image-20210904185336318.png

这个错误表示：

  1. 此时我们触发了一个 《错误级别的错误》
  2. 触发该错误的位置是 在 Home.vue 的第 13 行 第九列 中
  3. 错误描述为：字符串必须使用单引号
  4. 错误规则为：quotes

那么想要解决这个错误，通常情况下我们有两种方式：

  1. 按照 ESLint 的要求修改代码
  2. 修改 ESLint 的验证规则

按照 ESLint 的要求修改代码：

在 Home.vue 的第 13 行中把双引号改为单引号

修改 ESLint 的验证规则：

  1. 在 .eslintrc.js 文件中，新增一条验证规则

    "quotes": "error" // 默认
"quotes": "warn" // 修改为警告
"quotes": "off" // 修改不校验

那么这一小节，我们了解了 vue-cli 创建 vue3 项目时，Standard config 的 ESLint 配置，并且知道了如何解决 ESLint 报错的问题。

但是一个团队中，人员的水平高低不齐，大量的 ESLint 规则校验，会让很多的开发者头疼不已，从而大大影响了项目的开发进度。

试想一下，在你去完成项目代码的同时，还需要时时刻刻注意代码的格式问题，这将是一件多么痛苦的事情！

那么有没有什么办法，既可以保证 ESLint 规则校验，又可以解决严苛的格式规则导致的影响项目进度的问题呢？

ESLint 与 Prettier 配合解决代码格式问题

在上一小节中，我们提到《prettier 可以在保存代码时，让我们的代码直接符合 ESLint 标准》但是想要实现这样的功能需要进行一些配置。

那么这一小节，我们就来去完成这个功能：

  1. 在 VSCode 中安装 prettier 插件（搜索 prettier），这个插件可以帮助我们在配置 prettier 的时候获得提示

image-20210904195026475.png 0. 在项目中新建 .prettierrc 文件，该文件为 perttier 默认配置文件

  1. 在该文件中写入如下配置：

    {
  // 不尾随分号
  "semi": false,
  // 使用单引号
  "singleQuote": true,
  // 多行逗号分割的语法中，最后一行不加逗号
  "trailingComma": "none"
}

  2. 打开 VSCode 《设置面板》

image-20210904200638072.png 0. 在设置中，搜索 save ，勾选 Format On Save image-20210904200738067

至此，你即可在 VSCode 保存时，自动格式化代码！

但是！ 你只做到这样还不够！

  1. VSCode 而言，默认一个 tab 等于 4 个空格，而 ESLint 希望一个 tab 为两个空格
  2. 如果大家的 VSCode 安装了多个代码格式化工具的化
  3. ESLint 和 prettier 之间的冲突问题

我们尝试在 Home.vue 中写入一个 created 方法，写入完成之后，打开我们的控制台我们会发现，此时代码抛出了一个 ESLint 的错误

image-20210904200738067.png

这个错误的意思是说：created 这个方法名和后面的小括号之间，应该有一个空格！

但是当我们加入了这个空格之后，只要一保存代码，就会发现 prettier 会自动帮助我们去除掉这个空格。

那么此时的这个问题就是 prettier 和 ESLint 的冲突问题。

针对于这个问题我们想要解决也非常简单：

  1. 打开 .eslintrc.js 配置文件

  2. 在 rules 规则下，新增一条规则

    'space-before-function-paren': 'off'

  3. 该规则表示关闭《方法名后增加空格》的规则

  4. 重启项目

至此我们整个的 perttier 和 ESLint 的配合使用就算是全部完成了。

在之后我们写代码的过程中，只需要保存代码，那么 perttier 就会帮助我们自动格式化代码，使其符合 ESLint 的校验规则。而无需我们手动进行更改了。

git Husky和eslint

虽然我们已经要求项目使用eslint了，但是不能保证组员提交代码之前都将eslint中的问题解决掉了：

  • 也就是我们希望保证代码仓库中的代码都是符合eslint规范的；
  • 那么我们需要在组员执行 git commit 命令的时候对其进行校验，如果不符合eslint规范，那么自动通过规范进行修复；

那么如何做到这一点呢？可以通过Husky工具：

  • husky是一个git hook工具，可以帮助我们触发git提交的各个阶段：pre-commit、commit-msg、pre-push

如何使用husky呢？

这里我们可以使用自动配置命令：

前提是需要有git没有就git init

npx husky-init && npm install

这里会做三件事：

1.安装husky相关的依赖：

image-20230202105858503.png

2.在项目目录下创建 .husky 文件夹：

npx huksy install

image-20230202105927196.png

3.在package.json中添加一个脚本：

image-20230202105938160.png

接下来，我们需要去完成一个操作：在进行commit时，执行lint脚本：

image-20230202110401915.png

这个时候我们执行git commit的时候会自动对代码进行lint校验。

git commit规范

代码提交风格

通常我们的git commit会按照统一的风格来提交，这样可以快速定位每次提交的内容，方便之后对版本进行控制。

image-20230202110643713.png

但是如果每次手动来编写这些是比较麻烦的事情，我们可以使用一个工具：Commitizen

  • Commitizen 是一个帮助我们编写规范 commit message 的工具；

1.安装Commitizen

npm install commitizen -D

2.安装cz-conventional-changelog，并且初始化cz-conventional-changelog：

npx commitizen init cz-conventional-changelog --save-dev --save-exact

这个命令会帮助我们安装cz-conventional-changelog：

并且在package.json中进行配置：

image-20230202110822938.png 这个时候我们提交代码需要使用 npx cz：

  • 第一步是选择type，本次更新的类型
Type作用
feat新增特性 (feature)
fix修复 Bug(bug fix)
docs修改文档 (documentation)
style代码格式修改(white-space, formatting, missing semi colons, etc)
refactor代码重构(refactor)
perf改善性能(A code change that improves performance)
test测试(when adding missing tests)
build变更项目构建或外部依赖（例如 scopes: webpack、gulp、npm 等）
ci更改持续集成软件的配置文件和 package 中的 scripts 命令，例如 scopes: Travis, Circle 等
chore变更构建流程或辅助工具(比如更改测试环境)
revert代码回退
  • 第二步选择本次修改的范围（作用域）

image-20230202111127044.png

  • 第三步选择提交的信息

  • 第四步提交详细的描述信息

image-20230202111149155.png

  • 第五步是否是一次重大的更改

image-20230202111217802.png

  • 第六步是否影响某个open issue

image-20230202111228602.png

image-20230202111439100.png

我们也可以在scripts中构建一个命令来执行 cz：

代码提交验证

如果我们按照cz来规范了提交风格，但是依然有同事通过 git commit 按照不规范的格式提交应该怎么办呢？

  • 我们可以通过commitlint来限制提交；

1.安装 @commitlint/config-conventional 和 @commitlint/cli

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

2.在根目录创建commitlint.config.js文件，配置commitlint

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

3.使用husky生成commit-msg文件，验证提交信息：

npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"
avatar
文章
阅读
粉丝