Git 并不复杂，但有些方面却错综复杂，需要深入了解，比如 Git 钩子。例如 Git 钩子，它是 Git 根据特定事件自动运行的脚本。
虽然这些脚本可能很简单，但要有效地使用它们，却有更大的空间。不过，要做到这一点，你必须了解组成整个轮子的所有齿轮。
在本篇文章中，我们将介绍 Git 钩子的高级技巧，包括一些基础知识、如何创建和安装钩子等。在整个过程中，我们将解释钩子参数和环境变量，提供一些技巧和窍门，介绍故障排除方法，以及其他许多主题。
Git 钩子基础知识：入门指南
钩子是 Git 的关键功能之一：它是一种强大的机制，能让你自动执行任务、强制执行标准，并确保整个项目生命周期中工作流程的一致性。
Git 钩子是在 Git 工作流程中的特定节点自动执行的脚本。你可以用它们来定制和扩展 Git 的行为，以满足项目的需要。钩子能确保代码质量、测试运行和部署的顺利进行。
Git 提供多种类型的钩子，每种钩子都会在 Git 工作流程的不同阶段触发：
- 预提交。这些钩子在最终提交前运行，让你可以执行代码样式、运行测试或检查语法错误。
- 提交后。这将在创建提交后执行。对于通知或日志记录很有用。
- 预推送。该钩子会在推送代码前触发，可用于执行集成测试、检查兼容性或确保质量。
- 推送后。最后一个钩子在完成推送后运行。因此，它对于将代码部署到生产环境或更新文档很有价值。
你可以在 Git 仓库的 .git/hooks 目录中找到钩子。其中还有示例钩子–你可以用它们作为模板，创建自己的自定义脚本。钩子涵盖一系列操作，并使用 sample- 前缀以供参考：
显示示例钩子文件的本地 Git 目录。
钩子会在各种 Git 操作中触发。例如，提交前钩子会在提交更改时运行，推送前钩子会在推送到远程之前触发。进一步了解这些触发器后，你就能更有策略地部署钩子，以加强质量控制并简化工作流程。
如何创建和安装自定义 Git 钩子
创建和安装基本的自定义 Git 钩子可能是一个复杂的过程。不过，这里的基础知识将为你以后开发高级钩子打下基础。让我们来看看适用于创建和安装的每个钩子的几个概念。
选择合适的钩子类型
为特定用例选择合适的钩子类型是重要的第一步。您可以从了解自己的开发工作流程和需求开始。下面是一份相关注意事项的快速清单：
- 首先，考虑流程的各个阶段，如编码、测试和部署。此外，还要确定该流程在哪些方面可以受益于自动化和检查。
- 然后，找出工作流程中经常出现错误或不一致的地方。自定义 Git 钩子可以在这方面提供帮助。例如，如果您忘记在提交前运行测试，预提交钩子就能解决这个问题。
- 接下来，考虑何时在工作流中执行钩子。例如，如果您想确保所有提交都符合编码标准，那么预提交钩子就很合适。如果您想在推送到远程之前验证代码，则更适合使用预推送钩子。
- 最后，确保所选钩子类型与开发环境和工具兼容。考虑钩子将使用的脚本语言及其执行环境。
至此，您应该能够为钩子确定明确的目标。甚至可能每个目标都需要不同类型的钩子。不过，虽然为每种可能的情况创建脚本很有诱惑力，但最好还是先集中精力解决关键痛点。
命名和放置自定义 Git 钩子
正确命名和放置自定义 Git 钩子对于确保其功能性和可维护性至关重要。与代码中的函数、文件、类名等一样，您的 Git 钩子也应采用一致且具有描述性的命名规范。
如果钩子将作为模板长期支持多个项目，则可能需要使用前缀，比如开发者姓名首字母、部门或公司名称。一般来说，Git 钩子会使用小写字母和连字符来提高可读性，例如，my-project-pre-commit。
此外，虽然 Git 钩子可以存储在软件仓库的 .git/hooks 目录中，但自定义钩子应放在项目根目录下的单独目录中。这样可以防止 Git 更新时意外覆盖。不过，你应该对这些钩子和项目的其他代码一起实施版本控制。
如何创建基本的自定义 Git 钩子
编写基本 Git 钩子的典型方法是在钩子目录下新建一个文件，文件名为你选择的钩子（如 pre-commit）。我们将在稍后讨论参数时列出钩子名称。
在打开文件之前，应使用以下命令行片段确保文件可执行：
chmod +x path/to/file/hook-name
记住用正确的信息替换占位符。我们将在整篇文章中引用该代码段，因为它应该是您创建新 Git 钩子时的典型操作。
一旦文件可执行并打开，就可以使用自己喜欢的脚本语言添加自定义逻辑。可以是 Bash、Python、Ruby 等。当然，编写这些脚本语言超出了我们的讨论范围。不过，后面会有一些伪代码示例来展示特定的用例和场景。
最后，在提交任何变更之前，请尝试运行相关操作（如提交）来测试你的钩子。这是创建 Git 钩子的基本方法，但还有很多高级用例。接下来我们就来看看。
如何创建和安装高级自定义钩子
在你的开发生涯中，创建基本的 Git 钩子会是你经常做的事情。不过，在很多情况下，需要使用更高级、更复杂的钩子。接下来，我们就来看看各种常见情况下的钩子用例和示例。
使用线程器创建强制代码风格的钩子
使用联结器强制代码样式是 Git 钩子的一个绝妙应用。它有助于在整个版本库中保持一致的代码质量，并能从中获得很多价值。
当然，你应该选择适合你项目编程语言的连接器。例如，Black 就非常适合 Python。在这里，我们将使用 ESLint for JavaScript 来创建一个预提交钩子。
首先，在你的项目中安装一个全局包或本地包。为此，您需要 Node.js 和 npm：
npm install eslint --save-dev
接下来，导航到软件版本中的钩子目录。创建预提交文件，然后编写一个脚本，在暂存文件上运行线程。如果发现任何问题，钩子应阻止提交。下面是一个粗略的示例：
#!/bin/sh # Stash unstaged changes (optional but recommended) git stash -q --keep-index # Run the linter on staged files npm run lint # Replace with the appropriate linting command LINT_RESULT=$? # Unstash the stashed changes (optional but recommended) git stash pop -q # Exit with the linter's exit code exit $LINT_RESULT
确保钩子可执行后，通过提交进行测试。提交前的钩子应能运行内部程序。如果有任何违反代码风格的情况，在解决问题之前，你将无法完成提交。
当然，你应该根据自己的项目编写一个能与自己的编程语言和内核程序配合使用的钩子。例如，你可以将此示例扩展为 linter 配置设置、与构建过程集成等。
实现在提交前运行测试的钩子
实施提交前钩子，在提交前运行测试，是尽早发现潜在问题的绝佳方法。这样，你就能确保只提交通过可靠的代码。
在本例中，我们将使用 JavaScript 的 Jest 测试框架。你需要为自己的项目安装合适的框架（一如既往）：
npm install jest --save-dev
与每个钩子一样，导航到钩子目录，创建一个新文件，命名并使其可执行。在这里，编写一个脚本，在提交前对所有暂存文件进行测试。下面是一个粗略的模板：
#!/bin/sh # Stash unstaged changes (optional but recommended) git stash -q --keep-index # Run tests on staged files npm test # Replace with the appropriate test command TEST_RESULT=$? # Unstash the stashed changes (optional but recommended) git stash pop -q # Exit with the test's exit code exit $TEST_RESULT
尝试提交更改时，钩子会在暂存文件上执行测试。任何失败的测试都将停止提交，您应在重新提交前解决这些问题。
开发版本和标记自动化钩子
在 Git 中实现版本和标记自动化是简化发布流程的绝佳方法之一。这将确保整个代码库的版本一致。
首先，选择一个适合你项目的版本控制方案。这超出了本文的讨论范围，但常见的方案包括语义版本控制（Semantic Versioning，SemVer）或自定义版本控制模式。
接下来，确定您的钩子具体要做什么。例如，它可以读取当前版本，根据所选方案递增，并用新版本更新必要的文件。你还需要编写一个脚本，根据版本创建标签，使用 Git 命令创建轻量级或注释标签。
为文件创建并设置权限后，就可以开始编写钩子了。这可能是一个复杂且非常特殊的钩子，甚至会因项目而异。不过，这类钩子大多包括以下内容：
- 递增版本字符串（例如
1.2.3）指定部分并返回新版本的函数。 - 从专用版本文件中读取当前版本的功能。
- 计算新版本号的函数，包括递增的具体部分。例如，
0表示主要版本，1表示次要版本，2表示补丁。
在此基础上，脚本应使用新版本号更新版本文件，创建新版本的轻量级标签，并将新标签推送到远程版本库。提交更改后，钩子将确保每次提交都与相应的版本和标签相关联。
您可能还想让这个钩子进一步满足您的项目需求。例如，您可以处理创建初始标签、处理版本冲突和更新文件中的版本引用等情况。
了解钩子参数和环境变量
Git 钩子之所以如此强大，原因之一是它们如何处理动态变量。不过，这可能是一个复杂的概念。接下来，我们将从环境变量和钩子参数两方面入手。
参数如何传递给钩子
钩子可以从 Git 接收特定参数，以访问主代码库中的上下文信息。Git 会在运行时自动设置参数，虽然大多数情况下你并不需要特别定义参数，但你可能需要声明它们。要开发有效的钩子，了解这些参数至关重要。
下面是关于钩子参数的要点概述：
- Git 钩子使用位置变量，其中
$1指第一个参数，$2指第二个参数，以此类推。这些参数并不是任意设置的，它们有特定的含义和用途。因此，尽管它们不是 “官方” 的，但它们代表了访问参数值时公认的惯例。 - 参数的顺序遵循特定的模式。Git 会根据钩子事件的上下文，按预定顺序将这些参数传递给钩子脚本。
- 变量名反映了参数的一般用途。例如，
$1通常包含文件路径，而$2则可能是动作的源代码。
如果添加了钩子无法调用的参数，脚本一般就无法使用它。参数是特定钩子和执行上下文所特有的。为避免出现问题，应只使用记录在案的参数。不过，您可以将位置参数的值赋值给另一个变量，然后在脚本中使用它：
#!/bin/sh # Assign $1 to the variable EXAMPLE EXAMPLE=$1 # Use EXAMPLE variable echo "The commit message file is: $EXAMPLE"
在这种情况下， EXAMPLE 变量的值将与 $1 相同，即提交信息文件的路径。
不过，使用记录在案的变量名会让你的代码更容易理解。请注意，在某些情况下，你会使用标准输入 (stdin) 来定义参数，在这种情况下，你应该在钩子中加入这些元素。
查找 Git 钩子参数值和定义
由于每个 Git 钩子都有自己的参数，因此您可能需要参考资料来确定具体应用中的参数。好在有几种方法可以做到这一点。
例如，官方的 Git 钩子文档就包含了一些比较常见的参数。不过，最好的办法还是打开 Git 钩子示例。这些示例包括如何编写钩子脚本的迷你指南，其中还包括参数定义：
NeoVim 中的 Git 钩子文件示例。
这些都是掌握 Git 钩子的绝佳方法，甚至还能帮助你完成部分代码编写工作。
环境变量
Git 钩子可以从命令行参数和 stdin 获取参数，这一点我们已经讨论过。不过，它们也可以从运行在 bash shell 中的环境本身获取参数。
通过这些环境变量，你可以自定义 Git 钩子的行为，并根据 Git 工作流程的各个方面做出决定。这样，你就能创建动态的、能感知上下文的 Git 钩子。例如，你可以用它们来验证提交信息，控制对特定分支的访问，或根据作者身份触发自定义操作。
列出所有环境变量也超出了本篇文章的范围。我们建议你查看 Git 文档和示例钩子，了解它将使用哪些变量。
测试环境变量值
Git 通常会根据调用的钩子自动设置不同的环境变量。因此，如果你不知道环境变量被设置了什么，就会造成问题。例如，下面是 pre-rebase 和 post-merge 钩子的 GIT_REFLOG_ACTION 变量的结果：
pre-rebase.GIT_REFLOG_ACTION=rebasepost-merge.GIT_REFLOG_ACTION='pull other master'
幸运的是，有一种方法可以通过钩子中的一个小片段来测试 Git 对环境变量的处理：
#!/bin/bash echo Running $BASH_SOURCE set | egrep GIT echo PWD is $PWD
总结一下代码，第二行打印当前正在运行的脚本；第三行设置要显示的所有环境变量，然后过滤名称中包含 “GIT” 的变量；第四行打印当前工作目录。
运行该脚本后，你将看到与钩子相关联的环境变量相对应的输出。从这里开始，你将掌握如何确保自己的 Git 钩子能以自己喜欢的方式利用环境变量的知识。
管理和共享 Git 钩子的技巧和窍门
跨团队或跨组织管理 Git 钩子对于确保开发实践的一致性和高效自动化工作流程至关重要。举个简单的例子，分配一个专用的钩子目录。在此，我们可以给您两条建议：
- 创建一个中央存储库或共享位置，用于存储标准化钩子。您可以在多个项目中重复使用这些钩子，并克隆或链接到存储库以提供全局访问。
- 将钩子组织到注册表或目录结构中。这样可以方便团队查找和使用他们需要的钩子。
钩子越有可能出现在多个项目中，文档的重要性就越大。您应该维护全面的文档，概述每个钩子在 repo 中的目的、用法和配置选项。这些全局钩子的代码审查和更新策略也非常重要。
我们还建议您将自定义钩子与项目代码库一起存储在版本控制系统（VCS）中。这样可以确保整个团队都能访问整个钩子库。
使用服务器端 Git 钩子
服务器端钩子将在托管中央 Git 仓库的服务器上执行。因此，你可以在服务器端执行策略、执行检查或触发操作。
服务器端钩子有两种存储方式：与项目一起存储在 VCS 中，或存储在单独的仓库中。
使用 VCS 存储服务器端钩子
使用 VCS 存储服务器端钩子有两个好处。首先，您可以确保钩子与代码库的其他部分拥有相同的版本和维护。其次，您只需克隆一个版本库即可访问项目代码和钩子。
不过，根据特定钩子的性质，如果这些钩子访问敏感信息，将它们存储在同一个版本库中可能会引发安全问题。此外，如果钩子很复杂或需要特定配置，可能会增加主 repo 的复杂性。
将服务器端钩子存储在不同的版本库中
将服务器端钩子保存在单独的版本库中，可让您独立于代码库进行更新和版本控制，从而减少潜在冲突。这种模块化可以提供更大的灵活性。
此外，您还可以将这些钩子存储在限制访问的版本库中。这将有助于降低敏感数据暴露的风险。
相比之下，维护多个存储库可能需要付出额外的努力。此外，如果钩子依赖于主代码库的特定版本，那么在版本库之间协调更改也是一项挑战。
钩子安装自动化
在多个版本库中自动安装钩子可以节省时间，并确保开发工作流程的一致性。通过使用脚本和模板，您可以轻松地在不同版本库中设置钩子，而无需人工干预。
这一过程从包含全局钩子的专用资源库开始。您需要将这些钩子标准化：例如，避免硬编码单一软件源的特定路径或值。
在此基础上，就可以开始编写安装脚本了。例如，下面的伪代码将克隆钩子的模板仓库，并将钩子复制（或 “symlink”）到每个仓库的 .git/hooks 目录中：
# Example installation script # Usage: ./install_hooks.sh /path/to/repository TEMPLATE_REPO="https://github.com/yourusername/hooks-template.git" REPO_PATH="$1" REPO_NAME=$(basename "$REPO_PATH") # Clone the template repository git clone --depth 1 "$TEMPLATE_REPO" "$REPO_NAME-hooks" # Copy or symlink hooks to the repository cp -r "$REPO_NAME-hooks/hooks" "$REPO_PATH/.git/" rm -rf "$REPO_NAME-hooks" echo "Hooks installed in $REPO_NAME”
保存更改后，您就可以为每个要安装钩子的 repo 运行安装脚本了：
./install_hooks.sh /path/to/repository1 ./install_hooks.sh /path/to/repository2 # …
需要更新或添加钩子时，请在模板资源库中进行更改。下次在版本库中运行安装脚本时，就会安装更新后的钩子。
Git 模板
Git 模板可让你为新仓库定义常用钩子和配置。在创建或克隆新仓库时，它们提供了一种系统化的方法，帮助你自动完成设置、配置和其他元素。这样，你就能确保每个版本库都符合你的典型和既定做法。
创建模板目录并添加钩子脚本后，就可以配置 Git 将该目录作为新仓库的模板。你可以为每个用户在全局或本地基础上进行设置。
全局配置时，请指向钩子模板目录：
git config --global init.templateDir /path/to/hooks-template
对于本地配置，您可以指定确切的 repo：
git init --template=/path/to/hooks-template
无论何时使用 git init 创建新仓库或克隆现有仓库，Git 都会自动将钩子模板目录的内容复制到新仓库的 .git 目录中。
最后，虽然模板钩子可以是通用的，但也可以根据特定需求定制钩子。例如，脚本可以检查特定仓库的钩子配置文件，如果存在，就使用它。
帮助您安全维护 Git 钩子的典型实践
使用 Git 钩子能有效实现流程自动化并强制执行典型实践。不过，如果管理不善，也有可能带来漏洞。
以下是您可以为自己的钩子实施的快速实践列表：
- 确保审查并限制钩子的权限，尤其是第三方示例。
- 始终对输入参数进行验证和消毒，以减少代码注入。使用安全实践，例如避免在脚本中直接使用用户输入。
- 确保钩子不包含机密信息。这就是环境变量或安全存储提供巨大价值的地方。
- 定期审查和测试钩子，防止意外消耗资源。这甚至可能导致分布式拒绝服务 (DDoS) 攻击。
您还需要实施彻底、全面的测试和审查流程。这将有助于在未来减少漏洞和其他错误。
验证
我们应该更多地讨论如何为钩子实施适当的验证和错误处理。这对于确保可靠性、稳定性和安全性至关重要。
例如，您必须始终验证钩子脚本接收到的任何输入或参数。不过，要确保良好的验证，你还可以做很多事情。您可以确保版本库处于钩子成功运行的预期状态。例如，在提交前钩子中，检查是否在提交前暂存了必要的文件。
Git 钩子文件的一部分，显示退出 0 代码作为结束行。
错误处理也很重要。退出代码在钩子中和在代码库中一样重要，错误日志和翔实的错误信息也是如此。与大型代码库一样，”Graceful failure” 应该是您的目标。
当然，在现实世界中，你的钩子可能需要更复杂的验证和错误处理逻辑。这意味着定期测试比以前更加重要。
意外破坏行动
意外时有发生，因此设置 Git 钩子来防止这些不必要的破坏性操作，对于防止数据丢失或损坏至关重要。钩子可以通过用户提示潜在的有害操作来起到安全网的作用。
预接收和预提交钩子在这方面非常有效。让我们快速了解一下这两种钩子的作用：
- 预接收钩子有助于服务器端检查。这将在接受来自客户端的新分支或标记之前触发。脚本应检查传入的引用，检查是否有强制推送或删除分支等操作，并提示用户确认。你还需要分析推送的引用，以确定它们是否涉及强制推送（
--force）或分支删除等操作。 - 预提交钩子在客户端工作，并在最终提交前运行。虽然它不能直接防止服务器上的破坏性操作，但可以帮助防止推送前的本地错误。你的脚本应分析暂存的更改，并在提交信息中查找
force push命令等元素。然后，向用户显示警告或错误信息。
不过，无论您采用哪种做法，它们都必须安全、高效，并能满足您的最佳需求。这需要全面的审查和测试策略。
审查和测试 Git 钩子
审查和测试钩子对于确保其正常运行并与开发工作流程保持一致至关重要。同行评审、清晰的文档、大量的评论等都有助于确保钩子为生产做好准备。
说到测试，重要的是使用不同的样本数据进行独立测试。您还可以实施自动回归或集成测试。
最后，我们建议您在不同的环境（如开发、暂存和生产服务器）中测试钩子，以确保它们提供一致的行为。实时日志设置在这方面会有所帮助，因为它可以展示数据在服务器之间移动时发生的情况。
如何排除钩子故障
和其他代码库一样，你也可能需要对钩子进行故障排除，甚至需要多次尝试。事实上，无论你的 Git 钩子类型是什么，你都会发现同样的错误会反复出现。其中很多都是影响所有类型项目的简单问题，比如语法错误、权限问题、使用相对路径或硬编码路径等等。
不过，检查是否缺少依赖项也是一个好主意，因为有些钩子依赖于外部工具、文件或库。因此，您必须在执行钩子的环境中提供这些工具、文件或库。
Git 钩子也会出现一些特殊问题。例如，钩子应该以非零的状态代码退出，以示失败。此外，钩子不应包含无限循环。如果不具备这两点，就会导致意想不到的行为，扰乱工作流程。
您还可能会发现，两个钩子之间的冲突会带来意想不到的交互和后果。所谓的 “竞赛条件” 也会影响您的预期。在这种情况下，两个或多个钩子会通过类似事件触发，但其中一个钩子会比另一个钩子先完成–这将对您预期的最终结果产生影响。
这就是审查和测试变得至关重要的地方。维护文档对于避免问题和确保钩子按预期运行也很重要。
说到文档，Git 自己的参考资料是必不可少的读物。事实上，除了这篇文章，或许还有独立的 Git 钩子指南网站（使用 GitHub Pages），你不需要太多的阅读材料。
GitHooks 指南网站
不过，你可能还想看看能帮你管理 Git 钩子的应用程序。Lefthook 在 GitHub 上有定期更新和大量支持，而 Husky 则能帮助你整理提交信息。
将钩子集成到持续集成（CI/CD）管道中的好处
CI/CD 管道与 Git 钩子配合得很好，因为这些脚本可以帮助你实现任务自动化，确保一致的质量，并提供安全检查。
例如，预提交钩子能让你运行代码质量检查，如套色、静态分析和格式化。在测试方面，您可以在预提交阶段触发单元测试、测试套件或其他自动化检查。另一方面，预推钩子可以让你运行集成测试、安全扫描等。
在 CI/CD 管道中使用钩子有很多好处：
- 一致性。钩子能让你在所有提交和部署中执行一致的做法，从而减少全面错误。
- 自动检查。您可以自动执行代码质量检查、测试、安全扫描和其他重要任务。这将减少人工操作，让你有更多时间投入到其他方面。
- 早期问题检测。钩子可让您在开发过程中及早发现问题，从而防止问题在管道中传播。
- 降低部署风险。通过钩子触发的自动检查和测试，可以显著降低部署错误代码的风险。
WP Pusher 主页
当然，这也意味着您也可以选择使用 Git 钩子。
小结
Git 是任何开发项目都不可或缺的工具，但其中有一个方面尤其能为您的编码和部署工作流程带来极大的便利。Git 钩子可以让你使用多种语言创建脚本，自动执行版本控制流程的各个方面。这是一个简单的概念，但背后却有些复杂。
我们的文章将向你展示如何使用高级技术来充分利用 Git 钩子。你可以在本地和服务器端使用它们，使用参数和变量使其动态化，还能与多个远程仓库协同工作，等等。事实上，我们建议，在这一点上，Git 钩子可能会成为你提高工作效率、代码质量和项目周转时间的秘密武器。
关于 Git 钩子和使用方法，您还有什么问题吗？请在下面的评论区告诉我们！
原文地址：https://www.wbolt.com/git-hooks.html
