git commit --no-verify 仅跳过客户端本地的 pre-commit 和 commit-msg 钩子，不跳过 pre-push、pre-rebase 或服务端钩子；它通过阻止调用 .git/hooks/pre-commit 和 .git/hooks/commit-msg 文件实现，但可能因 husky 封装、别名冲突或参数未透传而失效。
git commit --no-verify 能跳过哪些钩子
--no-verify 只影响客户端本地的 pre-commit 和 commit-msg 钩子，不会跳过 pre-push、pre-rebase 或服务端钩子。它本质是告诉 Git：本次不调用 .git/hooks/pre-commit 和 .git/hooks/commit-msg 这两个文件——前提是它们确实存在且可执行。
常见错误现象：git commit -m "fix" --no-verify 仍报 ESLint 错误，大概率是因为：
- Husky 封装了提交命令（比如你配置了
git config alias.commit "!npm run commit"），参数没透传过去 -
.husky/pre-commit脚本里手动检查了NO_VERIFY环境变量，但你没加HUSKY=0 - 你实际触发的是
commit-msg钩子（例如 conventional commits 校验失败），而--no-verify对它无效——得用git commit -m "chore: xxx" -n或临时关掉HUSKY=0
为什么 git commit -n 有时比 --no-verify 更管用
-n 是 --no-verify 的简写，行为完全一致。但在某些旧版 Husky（如 v4.x）或自定义别名中，-n 更容易被识别。关键不是字母长短，而是参数是否被上层工具拦截。
使用场景：
- 终端直接运行
git commit -m "tmp" -n→ 通常有效 - 用
npm run commit触发 husky → 很可能失效，因脚本未转发-n - 在 VS Code 内置终端提交 → 检查是否启用了“Git: Enable Smart Commit”，它可能绕过命令行参数
验证方式：运行 git config --get alias.commit，如果返回类似 !git commit --no-verify，说明别名已固化跳过逻辑；如果为空，问题大概率出在 Husky 层。
HUSKY=0 git commit -m "xxx" 是最保险的临时方案
当 --no-verify 失效时，HUSKY=0 环境变量能直接让 Husky 完全不加载任何钩子脚本（包括 pre-commit、commit-msg、pre-push）。它不依赖 Git 参数透传，只作用于当前 shell 命令。
注意点：
- 仅对当前命令生效，不影响后续操作
- 必须写在
git commit前面，顺序不能错：HUSKY=0 git commit -m "xxx"✅，git commit -m "xxx" HUSKY=0❌ - Windows PowerShell 用户需改用
$env:HUSKY="0"; git commit -m "xxx" - 如果项目还用了
lint-staged且它被其他方式（如 npm script）调用，HUSKY=0不会影响它——得单独处理
直接删 .git/hooks/pre-commit 文件的风险与适用性
删除或重命名 .git/hooks/pre-commit 文件确实能一劳永逸跳过 pre-commit 钩子，但它只影响当前克隆副本，不进版本控制，也不影响队友。适合单机调试或 CI 本地复现。
但要注意：
-
.git/hooks/下的文件默认不被 Git 跟踪，所以删了也不会git status出来 - 如果项目用 Husky，它会在安装时自动把
.husky/pre-commit复制到.git/hooks/pre-commit，下次npm install可能恢复 - 删完记得确认权限：
ls -l .git/hooks/pre-commit，如果还存在但不可执行（-rw-r--r--），Git 根本不会运行它 - 别动
commit-msg或pre-push文件——除非你明确知道后果
真正容易被忽略的是：钩子是否由多层工具链叠加触发。比如 pnpm exec git commit + Husky + lint-staged + commitlint，这时单靠一个 --no-verify 很难覆盖全链路，得逐层确认入口点。
