Husky使用技巧

一、Husky 简介

Husky 是一个 Git 钩子管理工具，它允许你在 Git 操作（如提交、推送等）时执行自定义脚本。

1.1 安装 Husky

首先，确保你已经在项目中初始化了 npm 或 yarn 。然后，使用以下命令安装 Husky：

npx husky-init && npm install

上述命令会完成以下操作：

• 安装 husky 作为开发依赖。
• 在项目根目录创建 .husky 目录。
• 在 package.json 中添加 prepare 脚本，确保在 npm install 之后自动启用 Husky。
• 创建一个默认的 pre-commit 钩子。

1.2 添加commit-message钩子

要在 commit-message 钩子中使用 Conventional Commits 规范校验提交信息格式，可以借助 commitlint 工具。

• 安装依赖

  首先，需要安装 @commitlint/config-conventional 和 @commitlint/cli 这两个包。在项目根目录下执行以下命令：

npm install --save-dev @commitlint/{config-conventional,cli}

• 配置 commitlint

  在项目根目录下创建 commitlint.config.js 文件，并添加以下内容：

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

• 在 Husky 中添加 commit-msg 钩子

commit-msg 钩子会在你输入提交信息后、提交操作完成前触发。使用以下命令添加该钩子：

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

这会在 .husky 目录下创建一个 commit-msg 文件，内容如下：

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

npx commitlint --edit $1

通过以上步骤，你就可以在commit-msg 钩子阶段校验提交信息是否符合 Conventional Commits 规范。当你执行 git commit 并输入提交信息时，如果提交信息不符合规范， commitlint 会阻止提交操作，并给出相应的错误提示。

1.2.1 npx commitlint --edit $1命令详解

在 npx commitlint --edit $1 这个命令里，--edit 和 $1 有着不同的作用，下面用更通俗的方式结合例子来解释。

--edit 选项

--edit 就像是一个"文件读取器"指令。commitlint 是用来检查提交信息是否符合规范的工具，而 --edit 告诉 commitlint 从指定的文件里去读取提交信息，然后进行检查。

举个例子，想象你有一个笔记本（文件），里面写了一些内容（提交信息），commitlint 就像一个老师，--edit 就是让老师去翻开这个笔记本，看看里面写的内容是否符合作文规范（Conventional Commits 规范）。

$1 参数

在 Windows 的批处理脚本或者 Linux、macOS 的 shell 脚本里，$1 是一个"占位符"，它代表传递给脚本的第一个"小纸条"（参数）。在 Husky 的 commit-msg 钩子场景下，Git 会在你提交代码时，把记录你提交信息的临时文件的"地址"（路径）写在这个"小纸条"上，然后交给 commit-msg 脚本。

还是用上面老师检查作文的例子，$1 就像是告诉你老师笔记本放在哪里的"地址纸条"。当你运行 npx commitlint --edit $1 时，commitlint 老师就会根据这个"地址纸条"（$1）找到笔记本（临时文件），再用 --edit 翻开笔记本查看里面的内容是否符合规范。

整体示例

当你执行 git commit -m "feat: 添加用户登录功能" 时，Git 会把 "feat: 添加用户登录功能" 这个提交信息保存到一个临时文件里，然后把这个临时文件的路径作为第一个参数传递给 commit-msg 钩子脚本。commit-msg 脚本里的 npx commitlint --edit $1 命令就会让 commitlint 工具去读取这个临时文件里的提交信息，检查它是否符合 Conventional Commits 规范。如果符合，就允许提交；如果不符合，就阻止提交并给出错误提示。

1.3 Conventional Commits规范

Commit Log 规范有助于团队成员更好地理解代码变更的意图和目的。常见的 Commit Log 规范是 Conventional Commits，它的基本格式如下：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

各部分说明

1. type（必需） ：表示提交的类型，常见的类型有：

   • feat ：新增功能。
   • fix ：修复 bug。
   • docs ：文档变更。
   • style ：代码格式变更（不影响代码逻辑）。
   • refactor ：代码重构（既不是新增功能，也不是修复 bug）。
   • test ：添加或修改测试代码。
   • chore ：构建过程或辅助工具的变更。

2. scope（可选） ：用于描述提交影响的范围，例如模块名、功能名等。

3. description（必需） ：对提交的简短描述，使用祈使句，首字母小写，结尾不加句号。

4. body（可选） ：对提交的详细描述，可换行。

5. footer（可选） ：用于关联 issue、说明重大变更等

二、Husky工作原理

Husky 的工作原理基于 Git 钩子机制。Git 钩子是一些在 Git 执行特定操作（如提交、推送等）前后自动执行的脚本。这些钩子脚本位于项目的 `.git/hooks`` 目录下。

Husky 的主要作用是帮助你管理这些钩子脚本，避免手动编辑 .git/hooks 目录。当你使用 Husky 添加一个钩子时，它会在 .husky 目录下创建对应的脚本文件，并在 .git/hooks 目录下创建一个软链接，指向 .husky 目录下的脚本。这样，当 Git 触发钩子时，会执行 .husky 目录下的脚本。