前言： 企业编程必须始终依赖流程，而不是个人。个人能力很重要，应该鼓励，但不能指望它，否则软件质量将不一致，没有可持续性。一旦顶级程序员跳槽，公司就会陷入困境。企业应该努力改进工作流程，而不是努力改进人员，始终坚持流程优先于人员。
文章目录
Git hooks常见的 Hook 类型HuskyHusky 的原理Husky 初始化添加新的 hook
Lint-staged
自动生成 Commit Messagecommitlint
Git hooks
在团队协作开发中，代码规范的一致性和提交质量至关重要。Git Hook 是 Git 版本控制系统提供的强大机制，它允许开发者在特定 Git 事件（如提交代码、推送变更等）发生时触发自定义脚本。这些钩子脚本就像代码世界的自动哨兵，能在关键时刻执行预设的质量检查。
常见的 Hook 类型
钩子类型触发时机典型应用场景pre-commit提交消息输入前代码风格检查，单元测试commit-msg提交消息保存时校验提交信息格式pre-push推送到远程仓库前集成测试，构建验证post-merge合并操作完成后依赖安装，环境配置
Git Hook 默认存储在 .git/hooks 目录中，
Husky
Git Hook 都是使用 shell 脚本实现的，对不不熟悉 shell 脚本的人来说不太容易，同时shell 脚本再 Win/Linux/Mac 不同平台存在差异需要手动处理。所以需要借助 Husky 这个工具来简化 Git Hooks。
特性Git HooksHusky存储位置.git/hooks（不随代码提交）.husky（提交到版本库）团队共享需要手动复制到每个开发者的环境自动随代码同步，无需额外配置跨平台支持需要手动处理不同系统的差异自动处理 Windows/macOS/Linux 差异脚本管理需手动编写和维护提供命令行工具简化创建和修改错误处理需自行实现内置友好的错误提示和处理逻辑集成手动实现无缝对接 ESLint、Prettier 等工具链
Husky 的原理
Husky 的原理也很简单，就是复写了 Git Hook 部分的 Shell 脚本，依次调用 再 Husky 中配置的 npm scripts 将执行结果返回给 Git。
执行举例：
当 Git 触发某个 Hook（如 git commit 触发 pre-commit）时：
Git 会查找并执行 .husky 目录下对应的脚本脚本首先加载 husky.sh 以初始化环境执行用户定义的命令（如 npm run lint）根据命令的退出码决定是否继续执行： 4.1退出码 0：成功，Git 继续执行后续操作 4.2 非零退出码：失败，Git 终止当前操作（如阻止提交）
Husky 初始化
# 安装 Husky
npm install husky --save-dev
# 初始化Husky 同时会自动插入 "prepare": "husky", 到package.json
npx husky init
v8.0 之前的 Husky 使用 npx husky install 来初始化Husky，V8版本弃用。npx husky init 初始化 husky. 所以当使用 npx husky install 命令的时候会报错 husky - install command is DEPRECATED 为什么 husky install 被弃用？ 在 Husky 8.x+ 版本中，开发者移除了手动初始化命令，转而通过 npm 生命周期脚本 自动管理钩子。官方认为：
手动初始化容易遗漏（尤其在新成员加入项目时）自动初始化更符合现代 Node.js 项目规范
添加新的 hook
执行 echo "npm lint" > .husky/pre-commit 命令，将npm lint 命令添加到 pre-commit ，每次 commit 之前就会执行 npm lint 只要 npm lint 返回非 0，就会阻断提交。
// package.json
{
"scripts": {
"lint": "eslint . --fix",
}
}
Lint-staged
每次提交前会执行代码检查，如果项目文件特别多，每次提交时都会花费相当多的时间，所以就有了 lint-stage .它会根据配置使用对应的代码检查工具校验 stage 的文件，而不是所有的文件。也就是只检查变化了的文件。
安装 lint-staged
npm install --save-dev lint-staged # requires further setup
配置 lint-staged
{
....
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix"
],
"*.{json,md,yaml,yml}": [
"prettier --write"
]
....
}
自动生成 Commit Message
每次提交都要填写 Commit Message 以方便其它人了解其中的改动，改动较多或者复杂的时候，写起来比较麻烦。最新版的 VS Code 已经支持通过 Copilot 来辅助生成 Commit Message，安装 Github Copilot 插件并登录之后，点击 源码管理 面板的 Commit Message 输入框后方的Copilot 图标即可自动生成 Commit Message。
Copilot 默认生成的 Commit Message 只有一段描述，有时候中英文还不一定。为了生成一份标准格式的 Commit Message 我们可以通过配置文件，告诉 Copilot 应该生成一份什么样的 Commit Message。在 VS Code 的配置文件中添加如下配置：
{
...
"github.copilot.chat.commitMessageGeneration.instructions": [
{
"file": ".vscode/.copilot-commit-message-instructions.md"
}
]
...
}
然后再根据 file 指定的位置添加对应的 md 文件。 文件内容就是对要生成的 Commit Message 的要求，可以让 Copilot 或者 DeepSeek 辅助生成一份
然后再点击生成按钮，就可以生成符合标准的 Commit Message 了。
commitlint
commitlint 是用来校验 Commit Message 是否符合标准的，就不讲了，Copilot 生成的一般都是符合标准的 LOL。