即拉即用：你不知道的持续集成的3个Git Hooks详解

作者：Sarah Goff-Dupont

译者：月满西楼

在构建之外添加自动化的手段，是真正用好CI的关键。

如果你已经用了一段时间的Git了，相信你可能听说过Git Hooks，甚至可能简单的上手玩了玩。

Git Hooks在持续集成的语境中十分神奇，所以在本文中，我将深入介绍三个用例，并教你学会将现成可用的Hooks运用到你的工作流程中。 如果你还是Git Hooks的菜鸟，也完全不用担心， 因为我们将从基础开始。

1.了解Git Hooks

Hook是Git系统的本地机制，用于在诸如代码提交（Commit）和合并(Merge)之类的操作之前或之后触发的定制化脚本，可以把它们看作是Git的插件系统。对Git-hooks有一个入门认识的朋友都知道， 如果你进去查看Git的.git目录，你将看到一个“hooks”的子目录，里面包含很多Hook脚本。

安装Git Hooks其实很简单，网上也有很多供查阅的参考文档，在此就不讨论这个问题了。

按照Git Hooks脚本所在的位置可以分为两类： 客户端Hooks和服务器端Hooks。

客户端Hooks在本地工作站运行， 而服务器端Hooks则在你的Git服务器上运行。

还可以将Hook分类为Pre- 或Post-。Pre-receive Hooks脚本在某些特定的Git操作之前被调用, 可以利用这个Hook脚本来检查推送过来的提交是否合法，如不合法，Git操作不被执行，即客户端的推送会被拒绝。它们实际扮演一个保镖的角色，从后台保护代码库, 防止你和项目成员提交错误的代码。当从客户端（本地库）完成一个推送后， Post-receive Hooks将运行，它不会拒绝Git代码提交，但可以完成开发工作流程中的一系列自动化任务。

使用Git Hooks，就像拥有一个小机器人助手， 可以实现Git相关的一系列自动化任务 (哈哈！)

Git Hooks可实现项目开发流程的一系列自动化任务，例如下面几点：

• 验证你在提交消息中包含了关联的JIRA密钥
• 在代码合并前，确保满足先决条件
• 发送通知给你开发团队的聊天室
• 在切换到不同的工作分支后，设置你自己的工作区

2.创建稳定健康的工作分支

服务器端 Pre-receive Hooks是持续集成中的一个特别有力的补充，可以利用它来检查代码是否符合某些条件，防止开发人员随意将代码推送到master，就像精英忍者守护者一样，保护代码库不受恶意代码的影响。

开发人员通常都有足够的责任心，当他们在自己的工作分支测试上出现问题时，他们不会将分支合并到主程序。但有时我们却忘了检查，特别是当我们和其他人共享一个工作分支的时候，这时候会发生更多的更改或变化，虽然我们上次已经检查了分支的情况，但没想到问题还是出现了。。。。。。

此时，你就可以使用一个服务器端Hook，用于查找进入master的合并， 找到时， 脚本将检查分支上最新的构建，如果有测试失败的情况，那么合并就会被拒绝。我的同事和Atlassian的开发者Tim Petterson为此编写了一个Hook脚本

地址：https://bitbucket.org/tpettersen/git-ci-hooks/src/aad37a40bd0ffdef9a4188f1a7e1e5d768ca0fd1/update-green-builds-bamboo.rb

旨在与Bamboo合作，并使它在Bitbucket上可完美运用。 你可以把它抓下来，定制它，并将其添加到你的代码库中。

3.保护你来之不易的代码覆盖率

我看到很多开发团队都在努力维护代码覆盖率。 很多情况下，他们不得不通过测试来追溯他们的源代码库。在没有经过测试验证支撑的情况下，当很多功能被添加进来时，好不容易达成的代码覆盖率每况愈下，看到这样的情景，实在令人心灰意冷。因此，Tim还编写了一个pre-receive服务器端Hook，来保护master代码覆盖率不再下降。

地址：https://bitbucket.org/tpettersen/git-ci-hooks/src/aad37a40bd0ffdef9a4188f1a7e1e5d768ca0fd1/update-coverage-bamboo.rb

这个Hook也可以查找进入到master的合并，然后调用持续集成服务器来检查master以及分支上的代码覆盖率。如果分支的覆盖有任何问题，则合并将被拒绝。

大多数持续集成服务器不会通过它们的远程API显示代码覆盖数据，但Git Hook脚本可以获取代码覆盖报告。 要做到这一点，构建必须设置为将代码覆盖报告在master和工作分支上作为共享件发布。 一旦发布，你可以通过调用持续集成服务器从master获取最新的覆盖报告。对于分支覆盖，你可以从最新的构建中获取覆盖报告，也可以从正在提交的merge相关分支获取覆盖报告。

需要说明的是， 上述实践的前提是你已经运行了代码覆盖。别指望这个Hook来干这件事——它只是在你的构建结果中查找覆盖率数据而已。 默认情况下，这个脚本也适用于Bamboo，以及Clover（Atlassian的Java和Groovy代码覆盖工具）。但是它可以定制成与构建服务器或代码覆盖工具结合在一起使用。

4.检查分支构建的状态

朋友通常不会让朋友去检验有问题的分支。

那么此时，我们就可以利用另一个客户端Git Hooks: post-checkout Hook脚本，同样也是由Tim编写的，它在你的终端窗口中显示分支创建状态。该脚本从本地副本获取分支的头版本号，然后查询持续集成服务器，查看是否已经创建了该版本，并检查创建是否成功。

地址：https://bitbucket.org/tpettersen/post-checkout-build-status/src

比如，你想在master中创建分支，这个Hook会告诉你， master上的head commit是否成功建立，这意味着可以用这个“安全的”提交来创建分支。 再如，如果这个版本的分支构建失败了，但是开发团队的墙板却显示了一个绿色创建(或者正好反过来)。这意味着你的本地副本已经过期了，你可以自已决定是要更新版本还是继续使用旧版本的本地副本进行操作。

使用这个Hook对Atlassian的开发人员来说是无疑是一大神器，使他们避免了无数头痛的困扰。如果你实在不能说服你的开发团队采用上面讨论的服务器端Hook，那至少可以在你的本地工作站上安装一个，相信你绝对不会后悔的！

我在这里演示的所有用于持续集成的Git Hooks， 默认都是基于和Bamboo、Clover、Bitbucket 结合使用的情形,但是请记住，Git Hooks实际上是厂商无关的，因此你可以将它们定制成与你自已的编码工具结合使用，从而在开发过程中实现真正的自动化。

原文链接：https://www.atlassian.com/continuous-delivery/git-hooks-continuous-integration

关于作者：

莎拉是一位Atlassian敏捷交付传道者，之前是一名测试自动化工程师，还是简化书呆子式生活的忠实拥趸。例如，像持续集成和自动化一样。手动测试越来越变得枯燥无趣，她试图作出一些改变。她所崇拜的人包括玛格丽特·撒切尔夫人、麦吉弗和她的母亲。