在上篇文章中，我们深入探究了Git的目录结构以及各个目录文件的作用。然而，我们遗漏了一个重要的目录——.git/hooks。根据名字直译过来，.git/hooks指的就是Git钩子。那么，Git钩子到底能够用来做什么呢？在日常工作中应该如何使用呢？

一、基本介绍

1.1 引言

当我们在日常使用Git执行commit、push等命令时，Git版本库会记录下这些数据的变动，并一直保存。为了保证代码的安全性和提高代码质量，有时我们希望在用户执行commit、push等操作之前进行一些检查，这时就需要用到Git钩子。

1.2 Git钩子的概念和作用

Git钩子是一种机制，允许在特定的重要动作发生时触发自定义脚本。通过在Git钩子中编写相应的逻辑，可以在用户提交代码、推送代码等操作之前进行各种检测。这样可以帮助我们避免一些潜在的问题，比如不符合代码规范、存在语法错误、缺少必要的测试等。以下是一些Git钩子的常见作用：

代码风格和规范检查：使用pre-commit钩子，在提交(commit)之前执行代码风格和规范检查，以确保代码的一致性和质量。这可以帮助团队遵循统一的编码规范，减少代码错误和维护成本。
代码测试和质量检查：使用pre-push钩子，在推送(push)之前执行代码测试和质量检查，包括单元测试、集成测试、代码覆盖率检查等。这可以确保推送到远程仓库的代码是经过充分测试和质量验证的。
版本号自动更新：使用prepare-commit-msg钩子，在创建提交(commit)消息之前自动更新版本号等相关信息。这可以减少手动操作，提高版本控制的准确性和效率。
发送通知和集成：使用post-update钩子，在每次接收(push)操作之后发送通知或集成到其他系统，如飞书、Jenkins等。这可以及时通知团队成员代码的变更，并触发自动化的构建和部署流程。
文档生成：使用post-update钩子，在每次接收(push)操作之后自动生成文档，如API文档、用户手册等。这可以确保文档与代码的同步更新，提高文档的可靠性和可访问性。
安全性检查：使用pre-receive钩子，在接收(push)之前执行安全性检查，包括敏感信息泄露检查、权限验证等。这可以帮助保护代码和数据的安全性。

1.3 客户端钩子和服务端钩子的区别

Git有两组这样的钩子：客户端和服务器端。客户端钩子是在本地Git仓库上运行的脚本，它们通常用于在提交(commit)、推送(push)、合并(merge)等操作之前进行一些检查或操作。服务器端钩子是在远程Git仓库上运行的脚本，它们通常用于在接收(push)、合并(merge)等操作之前或之后执行一些逻辑。

二、详细介绍

2.1 示例文件

Git 默认会在.git/hooks目录中放置一些示例脚本。这些脚本除了本身可以被调用外，还透露了被触发时所传入的参数。所有的示例都是 shell 脚本，其中一些还混杂了 Perl 代码，这些示例的名字都是以 .sample 结尾，如果启用它们，先移除.sample后缀即可。把一个正确命名（不带扩展名）且可执行的文件放入 .git 目录下的 hooks 子目录中，即可激活该钩子脚本。这样一来，它就能被 Git 调用

admin@admindeMacBook-Pro LearnGit % tree .git/hooks
.git/hooks
├── applypatch-msg.sample
├── commit-msg.sample
├── fsmonitor-watchman.sample
├── post-update.sample
├── pre-applypatch.sample
├── pre-commit.sample
├── pre-merge-commit.sample
├── pre-push.sample
├── pre-rebase.sample
├── pre-receive.sample
├── prepare-commit-msg.sample
├── push-to-checkout.sample
└── update.sample

1 directory, 13 files

2.2 客户端钩子

当克隆某个版本库时，它的客户端钩子并不会被克隆下来。这是因为客户端钩子是与特定的本地代码库相关联的，而”clone”操作是将远程代码库复制到本地，新的本地代码库没有与之关联的客户端钩子。客户端钩子作用

applypatch-msg：在应用补丁消息之前运行，用于在提交消息中进行一些自定义操作。可以用于验证提交消息的格式或添加自定义标记。例如检查是否包含必要的信息、是否符合特定的模板等、自动填充提交消息的某些字段，例如作者、日期等。
commit-msg：在提交消息被创建之后运行，用于在提交消息被创建之后进行一些自定义操作。可以用于验证提交消息的格式、添加签名或自动填充信息。
pre-applypatch：在应用补丁之前运行，用于在应用补丁之前进行一些自定义操作。可以用于检查补丁的合法性、执行测试或其他自定义操作。
pre-commit：在提交之前运行，用于在提交之前进行一些自定义操作。可以用于运行代码风格检查、执行单元测试或其他自定义操作，以确保提交的代码质量。
prepare-commit-msg：在创建提交消息之前运行，用于在创建提交消息之前进行一些自定义操作。可以用于自动填充提交消息、添加注释或其他自定义操作。
pre-push：在推送之前运行，用于在推送之前进行一些自定义操作。可以用于运行测试、检查代码冲突或其他自定义操作，以确保推送的代码质量和一致性。
pre-rebase：在变基操作之前运行，用于在变基操作之前进行一些自定义操作。可以用于检查变基的冲突、执行测试或其他自定义操作。
fsmonitor-watchman.sample：在使用文件系统监视器时运行，用于在使用文件系统监视器时进行一些自定义操作。
pre-merge-commit.sample：在合并提交之前运行，用于在合并提交之前进行一些自定义操作。

2.3 服务端钩子

服务端钩子作用

pre-receive：在接收到推送操作之前运行，用于在接收到推送操作之前进行一些自定义操作。可以用于验证推送的分支、检查权限或其他自定义操作。
update：在引用被更新之前运行，用于在引用被更新之前进行一些自定义操作。可以用于限制分支的更新、检查权限或其他自定义操作。
post-update：在服务器上的每次更新之后运行，用于触发一些后续操作，如通知、部署等。
push-to-checkout：在检出之前运行，用于在检出之前进行一些自定义操作。可以用于验证检出的分支、检查权限或其他自定义操作。

三、代码示例

3.1 客户端钩子示例

检测代码中是否含有password，如果检测到该字符串禁止提交(PS：实际业务可以做许多其他事情，如代码提交是否符合规范等等)

#!/bin/bash

# 定义要搜索的字符串
PAASSWORD_PATTERN="password"

# 遍历所有将要提交的文件
for file in $(git diff --cached --name-only); do
  # 只检查文本文件
  if file "$file" | grep -q "text"; then
    # 搜索文件中是否包含 password 字符串
    if grep -q "$PAASSWORD_PATTERN" "$file"; then
      echo "Error: password detected in file $file"
      exit 1
    fi
  fi
done

# 没有检测到 password，允许提交
exit 0

客户端钩子前提，用户一定要给钩子加个可执行权限，否则不生效在执行git commit 的时候，发现检测到本次提交代码中含有password，commit 失败。

3.2 全局配置

执行Git clone操作的时候，它的客户端钩子并不会被克隆下来。用户设置的git commit文件也仅仅支持当前项目生效。每个开发维护的项目都比较多，一些统一的规范如检测是否有硬编码、commit msg信息是否正确，需要统一的对全局项目进行生效。

方式一

在Git 2.9+ 版本之后支持core.hooksPath设置

#创建hooks文件夹
mkdir -p ~/.git-hooksPath/hooks
#配置全局git hooksPath
git config --global core.hooksPath ~/.git-hooksPath/hooks  
#确保脚本可以执行
chmod a+x ~/.git-hooksPath/hooks/pre-commit

将hook的脚本放入~/.git-hooksPath/hooks中即可。

方式二

这种方式会在项目git init的时候，自动创建一个hooks文件夹，然后把所有的hook脚本都放在这个文件夹下，如果是旧的项目就需要再次执行git init才会生效。

#创建hooks文件夹
mkdir -p ~/.git-templates/hooks
#配置全局git templates
git config --global init.templatedir '~/.git-templates'  
#确保脚本可以执行
chmod a+x ~/.git-hooksPath/hooks/xxx

将hook的脚本放入~/.git-templates/hooks中即可。

四、总结

4.1 Git钩子优势

自动化操作：Git钩子允许在特定的Git事件发生时执行自定义脚本。这样可以自动化各种操作，如代码检查、测试、构建、部署等。通过自动化，可以减少手动操作和人为错误，提高开发流程的效率和可靠性。
代码质量保证：通过在钩子中执行代码风格和规范检查、代码测试和质量检查等操作，可以确保代码的质量和一致性。这有助于避免常见的编码错误、提高代码可读性和可维护性，促进团队成员之间的协作和代码复用。
团队协作和一致性：通过使用Git钩子，可以强制执行团队共同的开发流程和规范。无论是在代码提交之前的代码审核、代码测试和质量检查，还是在代码推送之后的自动化构建和部署，都能够确保团队成员之间的协作和代码一致性。
安全性和稳定性：通过在Git钩子中执行安全性检查和错误处理，可以提高代码和系统的安全性和稳定性。例如，可以在接收(push)操作之前进行权限验证、敏感信息泄露检查等，以防止潜在的安全漏洞和风险。
可扩展性和定制化：Git钩子是可定制的，可以根据团队的需求和流程编写自定义脚本来满足特定的要求。无论是简单的代码风格检查，还是复杂的自动化集成和部署流程，都可以通过Git钩子来实现。

4.2 常见问题

如何配置钩子脚本？钩子脚本位于.git/hooks目录下，可以在该目录下创建或编辑相应的脚本文件，并确保其可执行权限。
如何调试钩子脚本？可以使用echo语句将调试信息输出到终端，也可以使用日志文件记录钩子脚本的执行过程。
钩子脚本执行失败会发生什么？如果钩子脚本执行失败（即返回非零的退出代码），Git操作将被中断，并显示相应的错误消息。
如何跳过钩子脚本的执行？可以使用git命令的–no-verify选项来跳过钩子脚本的执行，例如：git commit –no-verify。
如何共享钩子脚本？可以将钩子脚本放置在共享的Git模板仓库中，并使用git init –template=命令来初始化新的仓库，也可以全局设置core.hooksPath 参数