工程化推进难？Git Hooks 被吐槽卡顿、破坏工作流的破局指南

在团队中推进 Git Hooks（如 Husky + Lint-staged）或类似的自动化检查工具时，几乎所有 Leader 都会遇到两个经典挑战：“老员工觉得这玩意儿卡，破坏节奏”以及“线上出 Bug 急着修复，钩子却挂了发不出去”。

如果处理不好，工程化建设就会变成“形式主义”，甚至导致团队关系紧张。今天我们从技术优化、心理博弈和应急响应三个维度，聊聊怎么把这套东西真正落地。

一、 解决“卡顿”：不要让规范变成负担

当有人抱怨“卡顿”时，他们通常不是在找借口。如果一个 Git Commit 需要等待 30 秒甚至 1 分钟，这确实是工程设计的失败。

1. 坚持“增量”原则

不要在 pre-commit 里跑全量 Lint。必须配合 lint-staged，只对本次提交的文件进行检查。如果一个项目有 2000 个文件，你只改了 2 个，检查耗时应该是秒级的。

2. 优化检查精度

检查工具是否配置了缓存？比如 ESLint 的 --cache 参数，能够极大提升二次检查的速度。
另外，检查一下钩子里是否包含了耗时极长的任务，比如“单元测试”或“构建打包”。这些任务不应该放在本地提交阶段，而应该移至远程 CI（持续集成）环境。

3. 区分“必要”与“可选”

如果你的检查项包含了格式化（Prettier）、逻辑检查（ESLint）和类型检查（TSC），请注意：TSC（TypeScript 类型检查）通常是最慢的。

• 策略建议：本地钩子只跑 ESLint + Prettier；复杂的类型检查和单元测试留给 CI。如果本地确实要跑 TSC，考虑使用 tsc-files 等工具进行增量检查。

二、 心理博弈：如何说服“不听话”的队友？

面对“破坏工作流”的质疑，强压手段往往适得其反。

1. 利益对齐：帮他“省时间”

你可以这样沟通：“现在的钩子确实稍微慢了一点点，但它能帮你挡住 CI 的失败。如果你提交了，CI 跑了 5 分钟后告诉你少了个逗号导致构建失败，你还得切换分支回来改，那个时间损耗是不是更大？”
将“本地约束”包装成“防止 CI 打回”的屏障。

2. 渐进式引入

不要一上来就加 100 条规则。可以先从“仅检查错误（Error）”开始，忽略“警告（Warning）”。等大家习惯了这种开发节奏，再慢慢收紧规则。

3. 赋予“一键跳过”的知情权

公开承认这套系统不是完美的。告诉团队成员，在极端情况下他们可以合法绕过，但需要承担相应的后果。这种“退路”能极大缓解开发者的抵触心理。

三、 应急响应：热修复时的“最优解”

当线上出 Bug，每一秒都在损失时，被 Git Hooks 挡住确实让人崩溃。

1. 快捷键：--no-verify

这是最直接的逃生通道。在执行提交时：

git commit -m "hotfix: fix critical production bug" --no-verify

这个参数会直接跳过所有 pre-commit 和 commit-msg 钩子。
注意：这必须是“最后手段”，且建议在团队规范中约定：使用 --no-verify 的提交，必须在 Merge Request 阶段进行更严格的代码审查。

2. 环境隔离策略

如果是因为某个依赖环境（如 Node 版本、二进制插件）导致钩子彻底崩了，可以直接在环境变量里临时禁用 Husky（如果你用的是 Husky）：

# macOS/Linux
HUSKY=0 git commit -m "emergency hotfix"

# Windows Powershell
$env:HUSKY=0; git commit -m "emergency hotfix"

3. CI 端的“强制兜底”

本地可以跳过，但远程 CI 绝对不能跳过。
最优的架构方案是：

• 本地钩子：为了快速反馈，追求体验。
• 远程 CI：为了最终质量，追求全量。
  即便开发者在本地使用了 --no-verify 提交了代码，CI 依然会进行全量扫描。如果 CI 挂了，代码依然无法合入主干。这既保证了紧急情况下的“快速提交”，又守住了质量的底线。

总结

一个好的自动化工具链应该是**“润物细无声”**的。如果团队反馈强烈，作为负责人首先要反思：

1. 我的钩子是不是跑了太重的东西？
2. 报错信息是否清晰（别让人猜哪里错了）？
3. 是否提供了清晰的应急逃生路径？

工程化的本质是提升效率，而不是为了规范而规范。 当你把工具优化到“无感”时，阻力自然就消失了。