来自man githooks:

未雨绸缪 这个钩子是由git commit调用的，可以通过——no-verify选项绕过。它 不接受参数，在获取建议的提交日志消息之前调用 做出承诺。从该脚本以非零状态退出会导致git 承诺中止。

——no-verify工作，但在我的情况下，我不想把参数一直放在终端上。所以我选择了更激进的方式。

如果你想全局禁用git钩子，你可以试试运行这个:

git config --global core.hooksPath /dev/null

但是，如果你想让它像以前一样，只需要在你的终端上运行下面的命令:

git config --global --unset core.hooksPath

如果你不希望它是全局的，只需删除参数:——global

我用Git 2.16.3测试了它。

出于某种原因，——no-verify对我来说没有用这个特殊的钩子:prepare-commit-msg

如果你也遇到了这个问题，试试:

SKIP=prepare-commit-msg git commit

您还可以临时从项目目录卸载预提交。我使用GUI应用程序合并，所以不能使用-n标志，注释掉行也不行。

pre-commit uninstall

完成后重新安装

pre-commit install

-n或——no-verify对于'git merge -continue'之后的提交无效。

这是另一个粗略的想法。

只需在文件.git/hooks/pre-commit中注释'#'符号即可。 执行单个或多个命令 取消注释 利润。

Maybe(来自git commit手册页):

git commit --no-verify -m "commit message"
           ^^^^^^^^^^^
-n  
--no-verify

这个选项绕过了pre-commit和commit-msg钩子。参见githooks(5)。

正如Blaise所评论的，-n对于某些命令可以有不同的作用。 例如，git push -n实际上是一个演练推。 只有git push -no-verify会跳过钩子。

注意:Git 2.14.x/2.15改进了——no-verify行为:

参见Kevin Willford(' ')的commit 680ee55(2017年8月14日)。 (由Junio C Hamano—gitster—在commit c3e034f中合并，2017年8月23日)

Commit:如果没有pre-commit钩子，则跳过丢弃索引

“git commit”用于丢弃索引并从文件系统中重新读取 以防预提交钩子在中间更新了它;这 当我们知道我们没有运行预提交钩子时，已经优化出来了。

Davi Lima在评论中指出，git不支持无验证。 所以如果一个cherry-pick触发了一个pre-commit钩子，你可能，就像在这篇博文中，必须以某种方式注释/禁用钩子，以便让你的git cherry-pick继续进行。

在合并冲突解决后，git rebase -continue也需要相同的过程。

在Git 2.36 (Q2 2022)中，run_commit_hook()的调用者将了解它获得“成功”是因为钩子成功了还是因为没有任何钩子。

参见提交a8cc594(修正了提交4369e3a1)，通过Ævar Arnfjörð Bjarmason (avar)提交9f6e63b (07 Mar 2022)。 (由Junio C Hamano—gitster—在commit 7431379中合并，2022年3月16日)

hooks:修复一个模糊的tocou“我们刚刚运行了一个hook吗?”比赛 署名:Ævar Arnfjörð Bjarmason

Fix a Time-of-check to time-of-use (TOCTOU) race in code added in 680ee55 ("commit: skip discarding the index if there is no pre-commit hook", 2017-08-14, Git v2.15.0-rc0 -- merge listed in batch #3). This obscure race condition can occur if we e.g. ran the "pre-commit" hook and it modified the index, but hook_exists() returns false later on (e.g., because the hook itself went away, the directory became unreadable, etc.). Then we won't call discard_cache() when we should have. The race condition itself probably doesn't matter, and users would have been unlikely to run into it in practice. This problem has been noted on-list when 680ee55 was discussed, but had not been fixed. Let's also change this for the push-to-checkout hook. Now instead of checking if the hook exists and either doing a push to checkout or a push to deploy we'll always attempt a push to checkout. If the hook doesn't exist we'll fall back on push to deploy. The same behavior as before, without the TOCTOU race. See 0855331 ("receive-pack: support push-to-checkout hook", 2014-12-01, Git v2.4.0-rc0 -- merge) for the introduction of the previous behavior. This leaves uses of hook_exists() in two places that matter. The "reference-transaction" check in refs.c, see 6754159 ("refs: implement reference transaction hook", 2020-06-19, Git v2.28.0-rc0 -- merge listed in batch #7), and the "prepare-commit-msg" hook, see 66618a5 ("sequencer: run 'prepare-commit-msg' hook", 2018-01-24, Git v2.17.0-rc0 -- merge listed in batch #2). In both of those cases we're saving ourselves CPU time by not preparing data for the hook that we'll then do nothing with if we don't have the hook. So using this "invoked_hook" pattern doesn't make sense in those cases. The "reference-transaction" and "prepare-commit-msg" hook also aren't racy. In those cases we'll skip the hook runs if we race with a new hook being added, whereas in the TOCTOU races being fixed here we were incorrectly skipping the required post-hook logic.