Git——Web Hooks原理与实战_simple-git-hooks

摘要

公司新人很多时候对代码代码的提交不是很清楚，同时作为项目的管理者的应该对公司的代码的进行的规范的管理，保证团队代码可读性和一致行，当你在推送后发现代码中有问题，甚至可以导致编译错误，或许你可以立即使用我们之前讲过的撤销操作的相关知识来重新提交一次。但是如果你的同事已经拉取了代码并且已经在他本地出现了错误呢？那么使用git的hooks的功能来实现的对代码的检查和流程的规范性进行的约束。

一、Hooks的类型？

为了防止这种情况出现，就需要我们今天要讲到的内容了，和其它版本控制系统一样，Git 能在特定的重要动作发生时触发自定义脚本。有两种钩子:

1. 客户端钩子
2. 服务器端钩子

客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。你可以随心所欲地运用这些钩子实现各种功能。

Hooks的安装

钩子都被存储在 Git 目录下的 hooks 子目录中。 也即绝大部分项目中的 .git/hooks。 当你用 git init 初始化一个新版本库时，Git 默认会在这个目录中放置一些示例脚本。 这些脚本除了本身可以被调用外，它们还透 露了被触发时所传入的参数。

所有的示例都是 shell 脚本，其中一些还混杂了 Perl 代码，不过，任何正确命名的可执行脚本都可以正常使用 —— 你可以用 Ruby 或 Python，或任何你熟悉的语言编写它们。 这些示例的名字 都是以 .sample 结尾，如果你想启用它们，得先移除这个后缀。把一个正确命名(不带扩展名)且可执行的文件放入 .git 目录下的 hooks 子目录中，即可激活该钩子脚本。 这样一来，它就能被 Git 调用。接下来，我们会讲解常用的钩子脚本类型。

二、钩子类型

本文主要讲客户端钩子，服务端钩子将在讲过服务端配置Git后再讲，客户端钩子分为三种：

1. 提交工作流钩子
2. 电子邮件工作流钩子
3. 其它客户端钩子

2.1 push操作工作流钩子

2.1.1 pre-commit

pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交。 你可以利用该钩子，来检查代码风格是否一致(运行类似 lint 的程序)、尾随空白字符是否存在或新方法的文档是否适当。

2.1.2 pre-merge-commit

pre-merge-commit钩子由git-merge调用，在合并操作执行成功，获得提交消息之前执行该钩子。该钩子不接收任何参数，如果脚本以非0值退出，将中止合并操作。如果在合并过程中出现了冲突，且处理冲突时并不是一次处理完成，而是分为了多个commit，这种情况下该钩子不会执行。

2.1.3 prepare-commit-msg

prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项:存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用;然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它，动态地插入信息。

2.1.4 commit-msg

commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。 在本章的最后一 节，我们将展示如何使用该钩子来核对提交信息是否遵循指定的模板。

2.1.5 post-commit

post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数，但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。

2.2 邮件通知工作流钩子

你可以给电子邮件工作流设置三个客户端钩子。 它们都是由 git am 命令调用的，因此如果你没有在你的工作 流中用到这个命令，可以跳到下一节。 如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。

2.2.1 applypatch-msg

applypatch-msg 。 它接收单个参数:包含请求合并信息的临时文件的名字。 如果脚本返回非零值，Git 将放弃该补丁。 你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。

2.2.2 pre-applypatch

pre-applypatch 。有些难以理解的是，它正好运行于应用补丁之后，产生提交之前，所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断git am的运行，这样补丁就不会被提交。

2.2.3 post-applypatch

post-applypatch运行于提交产生之后，是在git am运行期间最后被调用的钩子。你可以用它把结果通知给一个小组或所拉取的补丁的作者。 但你没办法用它停止打补丁的过程。

2.3 其它客户端钩子

2.3.1 pre-rebase

pre-rebase 钩子运行于变基之前，以非零值退出可以中止变基的过程。 你可以使用这个钩子来禁止对已经推送的提交变基。 Git 自带的 pre-rebase 钩子示例就是这么做的，不过它所做的一些假设可能与你的工作流程 不匹配。

2.3.2 post-rewrite

post-rewrite钩子被那些会替换提交记录的命令调用，比如git commit --amend和git rebase(不过 不包括 git filter-branch)。 它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。 这个钩子的用途很大程度上跟 post-checkout 和 post-merge 差不多。

2.3.3 post-merge

在git merge成功运行后，post-merge钩子会被调用。你可以用它恢复Git无法跟踪的工作区数据，比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。

2.3.4 pre-push

pre-push 钩子会在 git push 运行期间， 更新了远程引用但尚未传送对象时被调用。 它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。 你可以在推送开始之前，用它验证对引用的更 新操作(一个非零的退出码将终止推送过程)。

2.3.5 pre-auto-gc

Git的一些日常操作在运行时，偶尔会调用git gc --auto进行垃圾回收。pre-auto-gc钩子会在垃圾回收 开始之前被调用，可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。

2.3.6 post-checkout

在git checkout成功运行后，post-checkout钩子会被调用。你可以根据你的项目环境用它调整你的工作目录。 其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作

三、仓库中设置web hooks

有些钩子可以根据返回值决定是否继续执行后续动作，这些钩子是可以跳过的。只需要在执行命令时添加--no-verify可以跳过钩子的执行。

在自己的GitHub的项目中选中settings按钮，进入到webhooks的配置界面，然后选择左侧栏的webhooks进行配置。
 
详细的参数配置属性值，可以查看官方的文档https://developer.github.com/webhooks/，当然，基础的配置我们一眼就看出来了。
 
Web 挂钩可以安装在组织、特定仓库或 GitHub 应用程序 上。 安装后，每当发生一个或多个订阅事件时，都会发送 web 挂钩。
 
您可以为每个安装目标（特定组织或特定仓库）上的每个事件创建最多 20 个 web 挂钩。

创建 web 挂钩是一个两步过程。 首先需要设置 web 挂钩通过 GitHub 实施的行为 - 它应该侦听哪些事件。 之后，您将设置服务器以接收和管理有效负载。

向互联网显示本地主机：我们将使用本地服务器接收来自 GitHub 的消息。 因此，首先，我们需要将我们的本地发展环境显示给互联网。 我们将使用 ngrok 实现此目的。 所有主要操作系统均可免费使用 ngrok。（ngrok - download）在安装 ngrok 后，您可以在命令行上运行 ./ngrok http 4567 以暴露本地主机。 4567 是我们服务器侦听消息的端口号。 您应该会看到如下所示的行：

$ Forwarding    http://7e9ea9dc.ngrok.io -> 127.0.0.1:4567

博文参考

Git进阶教程-6-1-如何使用钩子检查代码和流程规范？ - 何方的编程之路

Git - Git 钩子
关于 web 挂钩 - GitHub Docs