Git Hooks 允许你在 Git 操作（如提交或推送）发生之前或之后运行自定义脚本，从而实现工作流程的自动化。它们能帮助你及早发现问题、强制执行代码标准，甚至自动修复问题。
例如，你可以编写一个脚本来强制执行代码风格标准，并将其添加到 pre-commit 钩子中。现在，每次有人尝试提交代码时，该钩子都会运行。如果代码通过了钩子中的检查，提交就会成功；否则，提交将被阻止。
Git Hooks 不仅仅用于标记问题，你还可以自定义脚本以在提交发生之前修复这些问题。本文将涵盖 Git Hooks 的所有内容，包括它们是什么、重要的钩子有哪些以及如何有效地实现它们。
什么是 Git Hooks？
Git Hooks 是在特定 Git 操作（例如提交、推送或合并之前或之后）发生时自动运行自定义脚本的机制。它们内置于 Git 中，无需安装任何外部库。
当你初始化一个 Git 仓库时，Git 会默认创建这些钩子。你可以在 .git/hooks 目录中找到它们。这些文件通常带有 .sample 扩展名，这使得它们默认不会运行。如果你想让它们运行，只需移除 .sample 扩展名即可。
你可以使用任何可执行的脚本语言编写钩子。例如，在 pre-commit 钩子文件中，你可以添加一个脚本，检查暂存文件中是否存在 “To-do” 注释，如果发现则阻止提交。这意味着每次你尝试提交时，Git 都会扫描以 “To-do” 开头的注释，如果发现未完成的任务，提交就会失败。通过这种方式，你可以为 post-commit、pre-merge、pre-push 等不同的 Git 操作创建自定义钩子。
Git Hooks 的类型
在深入研究实际示例之前，我们先了解 Git Hooks 的两种主要类型。
客户端 Hooks：类别与常见示例
客户端 Hooks 在本地机器上运行，通常在 commit（提交）、rebase（变基）和 push（推送）等 Git 操作期间触发。以下是一些常见的客户端 Hooks 及其具体用例：
pre-commit: 在你输入提交信息之前运行。可用于强制执行代码风格、运行测试或检查语法错误。prepare-commit-msg: 在 Git 创建默认提交信息之后、提交信息编辑器弹出之前运行。此钩子可以根据自定义脚本逻辑修改或替换默认信息。commit-msg: 在保存提交信息之后、Git 完成提交之前运行。这是强制执行提交信息规则（如格式、结构或标签）的最后检查点。post-commit: 在提交创建之后运行。常用于通知（例如在提交后发送 Slack 消息）或日志记录（存储提交元数据）。post-checkout: 在成功的git checkout命令之后运行。当切换分支、检出特定提交或路径时触发。可用于重建项目依赖、删除临时文件或通知新分支。post-merge: 在成功的merge（合并）操作之后运行。常用于更新依赖项、打印合并信息或清除缓存。pre-rebase: 在rebase（变基）操作之前运行。可用于阻止对受保护分支的变基、在允许变基前运行测试，或在存在未提交更改时停止变基。pre-push: 在push（推送）更改之前运行。有助于阻止推送到受保护分支或运行预推送测试。post-rewrite: 在 Git 成功重写提交后运行。在git commit --amend（重写最后一次提交）或git rebase（重写一系列提交）等操作上触发。用于在重写后更新引用或触发测试和 CI 步骤。pre-applypatch: 由git am命令调用，在补丁应用到工作树但新提交尚未创建之前运行。如果此钩子中的检查失败，它会以非零状态退出并阻止补丁被提交。post-applypatch: Git 在应用补丁并创建提交后运行此钩子。它无法中止提交，但适用于日志记录或发送通知。applypatch-msg: Git 在git am应用补丁之前运行此钩子。用于检查或编辑补丁的建议提交信息。
服务端 Hooks：类别与用例
服务端 Hooks 在远程 Git 服务器上运行，并在远程事件发生时触发，例如在推送到仓库之前或之后。
pre-receive: 远程服务器在接受推送之前运行此钩子。你可以用它来强制用户之间保持一致的代码风格，或者在接受客户端的更改之前运行安全检查。update: 与pre-receive每次推送只运行一次不同，update钩子会为单次推送中每个被更改的引用（分支或标签）运行一次。post-receive: 在 Gitpush（推送）操作完成后运行。常用于发送通知、全面的日志记录或触发 CI/CD 管道。post-update: 在 Git 更新推送中的所有引用后运行。可用于简单的通知，因为它不像post-receive那样可以访问每次引用更新的旧日志和新日志。reference-transaction: 在引用事务准备、提交或中止时触发，因此它可能会运行多次。用于验证或拒绝单个事务中多个引用的更新，或用于日志和审计引用更改。push-to-checkout: 当你推送到远程当前已检出的分支时触发。通过此钩子，你可以在推送后更新服务器上的文件、记录更改或阻止直接推送到工作目录的不安全推送。pre-auto-gc: 在 Git 触发自动垃圾回收之前运行。你可以用它来记录垃圾回收的开始、在资源密集型操作期间阻止垃圾回收，或处理任何必要的垃圾回收前任务。proc-receive: 当git-receive-pack命令处理传入的推送时运行。它会更新远程仓库中的引用（分支和标签），并将结果报告回客户端。
设置 Git Hooks
本节将介绍安装和设置 Git Hooks 的步骤，以及如何从头开始创建自定义钩子。
安装和配置机制
当你初始化一个 Git 仓库时，Git 会自动在 .git/hooks 文件夹中创建一组钩子。要查看它们，请打开你的终端并进入你运行 git init 的仓库根目录。从那里，打开隐藏的 .git 目录，然后进入 hooks 子目录。一个简单的 cd 命令可以为你完成所有这些操作，并提供对 hooks 子目录的访问。
cd .git/hooks
进入目录后，你会看到带有 .sample 扩展名的默认钩子。要启用默认钩子，请移除该钩子的 .sample 扩展名并使其可执行。
例如，使用以下命令从 pre-commit 钩子中移除 .sample 扩展名：
mv .git/hooks/pre-commit.sample .git/hooks/pre-commit
接下来，使用以下命令使其可执行：
chmod +x .git/hooks/pre-commit
这涵盖了编辑和启用默认钩子。要从头开始创建自定义钩子，请遵循以下步骤。
要在 .git/hooks/ 中打开一个新文件，运行：
nano .git/hooks/commit-msg
在此文件中创建脚本。示例：
#!/bin/sh
echo "✅ Commit message hook triggered"
保存并退出，然后使其可执行：
chmod +x .git/hooks/commit-msg
在上面的示例中，每当提交成功时，钩子都会打印一条消息 "✅ Commit message hook triggered"。
还有另一种设置自定义钩子的方法。当你初始化一个仓库时，Git 会包含默认钩子。你可以使用模板目录编辑这些默认钩子。
工作原理如下：当你运行 git init 时，Git 会将全局模板目录的内容复制到新仓库的 .git/ 目录中，包括钩子。如果你将自定义钩子脚本添加到全局模板目录中，你创建的每个新仓库都将自动继承这些自定义钩子。
创建和自定义 Hook 脚本
首先，你需要明确想要实现的目标。是捕获模糊的提交信息，防止意外推送，还是清除缓存？预先明确目标非常重要，因为不同的 Git Hooks 有不同的用途，你应该知道该使用哪个。
例如，如果你想检查提交信息的风格，你会使用 commit-msg 钩子。如果你想避免某些推送到 main 分支，你应该使用 pre-push 钩子。
一旦选择了钩子，下一个决定是语言。在 macOS 和 Linux 上，一个简单的 Bash（或纯 sh）脚本通常就足够了。在 Windows 上，一些团队倾向于使用 PowerShell。
如果你的仓库是多语言的，你可能更喜欢像 Python 或 Node.js 这样的通用解释器，这样每个人都可以运行相同的逻辑。因此，关键是在顶部包含一个 shebang（#!/bin/sh、#!/usr/bin/env python3 等），以便 Git 知道如何执行它。
一个简单的 pre-commit 钩子示例，它阻止提交 .env 文件。这可以避免意外推送敏感 API 密钥。
#!/bin/sh
# Block committing secrets
if git diff --cached --name-only | grep -q ".env"; then
echo "❌ .env file detected in commit! Remove it before committing."
exit 1
fi
exit 0
当你想要禁用钩子时，最简单的方法是暂时重命名它们（将 pre-commit 改为 pre-commit.off）或移除它们的执行权限。
然而，如果你只需要跳过一次，可以使用 git commit --no-verify 来跳过提交钩子，使用 git push --no-verify 来跳过推送钩子。你甚至可以通过将 Git 指向一个空文件夹来全局禁用钩子：git config core.hooksPath /dev/null。
Git Hooks 常见用例与示例
Git Hooks 在自动化测试、安全检查以及强制执行工作流中的质量标准方面特别有用。
实用自动化场景
强制代码风格或 Linting：pre-commit 钩子常用于在提交之前自动格式化代码并捕获潜在错误。
例如，在以下 pre-commit 钩子中，Prettier 会自动处理格式化并在提交前暂存更改。Linter 随后会运行，只有当 Linting 通过时，提交才会成功。如果 Linting 失败，提交将被阻止。
#!/bin/sh
# Collect staged JS/TS files
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts|tsx)$')
[ -z "$FILES" ] && exit 0
echo "Formatting with Prettier..."
npx --yes prettier --write $FILES
# Re-stage files that Prettier changed
echo "$FILES" | xargs git add
echo "Linting with ESLint..."
npx --yes eslint $FILES
STATUS=$?
if [ $STATUS -ne 0 ]; then
echo "ESLint found issues. Fix them or commit with --no-verify if needed."
exit $STATUS
fi
echo "Pre-commit checks passed."
exit 0
运行自动化测试：你可以设置钩子在推送任何更改之前运行自动化测试。例如，以下 pre-push 钩子会自动发现并运行仓库中可用的 pytest，然后再推送更改。
#!/bin/sh
echo "Running tests before push..."
pytest -q
STATUS=$?
[ $STATUS -eq 0 ] || { echo "Tests failed. Push aborted."; exit $STATUS; }
自动阻止提交敏感数据：像 .env、.pem 或 .key 等敏感文件通常包含秘密信息。以下 pre-commit 钩子示例检查此类模式，如果提交包含它们，则阻止提交。
#!/bin/sh
set -e
STAGED=$(git diff --cached --name-only --diff-filter=ACM)
# Block dotenv and private keys
echo "$STAGED" | grep -E '\.env(\.|$)|(^|/)\.env$|\.pem$|\.key$|id_rsa$' >/dev/null 2>&1 && {
echo "Sensitive file detected in staged changes. Remove it from the commit."
exit 1
}
编写高效 Git Hooks 的技巧
这里我总结了一些在编写 Git Hooks 时会很有帮助的技巧。
保持钩子快速执行
钩子在你触发某些 Git 操作时每次都会运行，所以请确保它们轻量化。如果你的测试套件很大，最好在 CI/CD 中运行它们，而不是在本地钩子中，以获得更好的性能。每次提交时对整个仓库运行代码检查、格式化或测试会减慢你的速度，所以请限制检查范围到实际更改的文件。
维护跨平台兼容性
确保你的钩子在不同的操作系统上都能顺利运行。使用可移植的 shebang，一致地处理行尾（优先使用 LF 而非 CRLF），并且不要硬编码绝对路径。
相反，依赖 PATH 和本地项目脚本，如 npm run lint 或 python -m，这样它可以在多个环境中运行。
调试策略
添加详细的日志记录或调试标志（例如 HOOK_DEBUG=1）来跟踪脚本的运行方式。打印当前目录、分支或正在暂存的文件等详细信息。这使得跟踪执行流程并发现问题变得更容易。
在推送更改之前，使用不同的输入测试钩子并在本地模拟失败场景。如果钩子意外阻止了进度，你可以使用 Git 的 --no-verify 标志或设计用于跳过钩子的环境变量暂时绕过它。
为了在不同操作系统之间保持一致的行为，避免使用特定于操作系统的命令，并优先使用可移植的脚本语言。
清晰地文档化钩子
良好的文档可以提高团队的理解，并简化新成员的入职。维护一个中心的 README 文件，详细说明每个钩子的目的、行为和用法。包括如何运行、先决条件、故障排除和绕过钩子的提示。此外，提供安装/设置说明。
Git Hooks 的高级实现技巧和最佳实践
如果你是高级用户，以下建议可能会有所帮助：
性能优化
为了优化复杂工作流中的性能，通过避免重量级库来减少外部依赖。这可以缩短启动时间并减少故障点。
缓存昂贵过程（如 linting）的结果，以便在文件未更改时可以重复使用它们。
如果钩子包含多个检查，请并行化它们，以便它们同时运行。此外，模块化钩子脚本。这意味着将钩子结构化为可重用的、小的组件，这些组件只根据上下文执行相关部分。
钩子链和编排
使用钩子链在单个 Git 事件中运行多个钩子。例如，在 pre-commit 钩子中，你可能希望运行 linting，然后运行测试，最后格式化代码，所有这些都串联在一起。每个命令依次运行，如果任何命令失败（以非零状态退出），后续命令可能会被跳过，以防止错误的提交。
当钩子操作是独立的时，你也可以并行运行它们以节省时间。这就是你使用编排来管理任务按正确顺序执行的地方。
配置管理
每个仓库都有自己的 .git/hooks 目录。这意味着如果你想在多个项目中进行相同的检查（例如 linting），你必须在每个地方复制粘贴它们。一个更好的方法是集中管理钩子，以便所有仓库都可以访问和运行它们。
你可以通过一个简单的命令实现这一点：git config --global core.hooksPath ~/.githooks。这会告诉 Git 在 ~/.githooks 文件夹中查找钩子。你在此处创建的任何钩子都会自动在所有仓库中共享。
你还可以使用配置文件（JSON 或 YAML）使钩子逻辑更具动态性。你的钩子脚本可以读取该仓库的配置文件，并自动应用正确的规则，而不是为每个仓库硬编码不同的逻辑。
条件执行
在钩子脚本内部，你可以添加简单的条件，使它们仅在相关时运行。这可能意味着检查当前分支名称，查看实际更改了哪些文件，或读取一个告诉它们跳过的环境变量。
如果你需要更多控制，可以使用 pre-commit 这样的框架，你可以在配置文件中声明在哪个阶段运行哪些钩子。你还可以添加条件逻辑，例如只在特定分支上运行钩子，使用变量跳过钩子，甚至添加基于时间的条件。这使得你的钩子脚本具有动态性，并能适应实际的工作流。
协作和共享策略
有两种方法可以集中管理 Git Hooks 并在仓库和团队之间共享：
Git 模板
当你初始化一个仓库时，Git 会在 git/hooks 目录下添加一些默认钩子。这些钩子来自 Git 的默认模板。
要集中创建自定义钩子，你可以创建一个 Git 模板目录，将你的钩子写入其中，并全局设置 Git 使用此新目录作为默认模板。
git config --global init.templateDir /path/to/hooks-template
但是，这种方法缺乏对钩子的版本控制。如果你的钩子很少更改，这会特别有用。如果你的钩子经常更新并且需要版本控制，你将需要使用下一种方法。
中心 Git 仓库
创建一个专用的、受版本控制的中央仓库，并将所有自定义钩子脚本存储在该仓库中，与项目仓库分开。这样，你可以独立于项目代码库更新钩子。
这些钩子应该标准化，这意味着避免硬编码路径或与单个仓库绑定的值。
这种设置对团队特别有用，因为每个人都可以定期拉取更新并将其同步到他们的项目中。
一种更有效的方法是使用设置脚本来克隆中央钩子仓库，并将钩子脚本复制到每个项目的 .git/hooks 目录中。示例设置脚本：
#!/usr/bin/env bash
set -euo pipefail
# Location of the shared hooks template repo
HOOKS_TEMPLATE_REPO="git@github.com:your-org/git-hooks-template.git"
HOOKS_TEMPLATE_DIR="$HOME/.git-hooks-template"
# Clone or update the template repo
echo "Cloning hooks template repo..."
git clone "$HOOKS_TEMPLATE_REPO" "$HOOKS_TEMPLATE_DIR"
# The repo where you want hooks installed
TARGET_REPO="${1:-$(pwd)}"
TARGET_HOOKS_DIR="$TARGET_REPO/.git/hooks"
# --- Copy strategy ---
echo "Copying hooks into $TARGET_HOOKS_DIR..."
cp -r "$HOOKS_TEMPLATE_DIR/"* "$TARGET_HOOKS_DIR/"
# 4. Make sure hooks are executable
chmod +x "$TARGET_HOOKS_DIR"/* || true
echo "✅ Hooks installed successfully into $TARGET_REPO"
另一种选择是使用符号链接（symlinks）。你可以将每个项目的 .git/hooks 目录链接到版本控制的钩子仓库中的脚本。这样，每当你更新中央仓库时，钩子都会自动更新，因为符号链接指向它。
为了保持这个系统的可靠性，建立一个清晰的钩子维护流程。团队成员应该通过 Pull Request 提出钩子更改，只有在审查后才合并，并随着钩子的演变保持文档更新。
将 Git Hooks 与开发工作流集成
Git Hooks 在持续集成（CI）中发挥着重要作用。在 CI 中，这意味着频繁合并更改，然后运行构建和测试以尽早发现问题。通过将 Hooks 与 Jenkins、GitHub Actions 或 GitLab CI 等 CI/CD 工具连接，你可以根据 Git 事件自动触发构建、运行测试甚至部署应用程序。
例如，一个服务端 pre-receive 钩子在 Git 服务器接受推送之前运行一个自定义脚本。如果脚本失败，服务器将拒绝推送。你可以用它来检查该分支的最新 CI 构建是否通过，然后再允许推送。该 CI 运行可能包括代码覆盖率检查、单元或集成测试，甚至安全扫描。
钩子还可以自动化部署任务。post-receive 钩子可以触发一个 Webhook，启动 CI/CD 管道。当代码合并到 main 分支时，它会自动启动构建 -> 部署 -> 发布周期。
安全考量与最佳实践
如果你维护中央钩子以方便协作和共享真相，请确保钩子目录具有安全的 文件权限，以防止未经授权的访问。只有受信任的用户才能拥有写入权限。
你必须始终验证钩子脚本接收的输入或参数，以避免代码注入攻击。例如，针对严格模式验证输入，如只允许包含字母数字和连字符的分支名称，或匹配 vMAJOR.MINOR.PATCH 的标签。
切勿在钩子脚本中硬编码敏感数据。相反，使用 环境变量 或专门的秘密管理工具在运行时安全地提供凭据。你可以将 Gitleaks 等工具与 pre-commit 钩子集成，以便在你即将提交的更改中扫描敏感信息。
有人可能会重定向你的钩子，将代码或信息发送到不同的服务器。因此，限制你的钩子可以访问的域。使用代理或防火墙来阻止未知目标服务器。此外，确保你的日志在显示消息中不包含机密信息。
总结
Git Hooks 是一种强大的工具，可以直接在你的开发工作流中自动化任务并强制执行标准。它们可以帮助处理从代码风格和测试到部署和安全检查的一切。
通过善用它们，你可以减少错误，节省时间，并使团队之间的协作更加顺畅。
从简单的 pre-commit 检查开始，然后尝试更高级的设置，如编排、集中管理或 CI/CD 集成。如果你是 Git 用户并希望提升你的技能，请查看相关的进阶 Git 课程。
Git Hooks 常见问题解答
Git Hooks 在哪里可以找到？
Git Hooks 的默认路径是 .git/hooks，这个文件夹通常是隐藏的，所以你只能在 Bash 或终端中访问它。
设置 pre-commit 钩子的最佳实践是什么？
保持钩子快速执行，并在暂存文件上运行以获得更高的性能。不要将 pre-commit 钩子用于耗时的任务，例如运行完整的测试套件；请在 CI/CD 管道中执行这些任务。并清晰地文档化它们的目的。
服务端 Git Hooks 与客户端 Hooks 有何不同？
客户端 Hooks 在开发人员机器上运行，用于提供反馈和自动修复。例如：pre-commit、pre-push。
服务端 Hooks 在 Git 远程服务器上运行，用于对无缝生产管道和有效的团队协作进行关键检查。例如：pre-receive、update。如果服务端钩子拒绝了推送，它就不会成功提交。
我可以使用 Git Hooks 来强制执行编码标准吗？
是的，可以使用 pre-commit 钩子进行代码格式化和 Linting；使用 commit-msg 钩子来强制执行提交消息约定；使用 pre-push 钩子进行快速测试；以及使用服务端 pre-receive 钩子来阻止秘密信息提交到远程仓库。
关于
关注我获取更多资讯
