git钩子放服务器_使用 git post-receive 钩子部署服务端代码

在 git 中提交服务器源码的时候，如果能够直接更新到测试服务器，并且重启服务使其生效，会节省懒惰的程序员们大量的时间。

git 的 Server-side hook (服务端钩子/挂钩)可以用来做件事。

本文以部署基于 OpenResty 的服务端程序为例来介绍我的做法。

技术信息

OS： CentOS 6.3

服务器软件： OpenResty

开发语言： Lua

名词解释

服务器： 服务器硬件 + OS

服务端程序： OpenResty 在服务器中的进程

服务端代码： 部署在 OpenResty 中的 Lua 源程序

一、git 服务端钩子类型

Pro git 中介绍了 git 钩子的几种类型，其中和服务端相关的有：

pre-receive

在客户端推送时最先执行，可以用它来拒绝客户端的推送。

update

与 pre-receive 类似，但会在每个分支都执行一次。

post-receive

在客户端推送完成后执行。

根据我的需求，我选择 post-receive 钩子来做这件事。因为我不希望拒绝客户端的推送(那样程序员们可能不知道该怎么办)。推送总是会成功的，只是 命令 不成功而已。碰到 命令 不成功的情况，客户端只需要再次推送一个正确的 命令 即可。

关于 命令 的配置，后面会详述。

二、git repostories

我建立了2个 git 仓库来完成这个任务。分成2个仓库的好处是，更新服务端代码和控制服务端程序互不干扰。

在开发服务器上，我可以将 OpenResty 的 lua file 缓存关闭。这样服务端代码更新后会立刻生效，不必重启服务端程序。

而如果服务端程序出现错误，只需要更新它的状态(reopen/reload 等)即可，不必更新服务端代码。

server.git

这个仓库保存服务端逻辑代码，客户端的文件夹结构如下：

server

├── README.md

└── src

└── main.lua

每次提交代码的时候，在提交信息中可以包含特定的 命令 ，在推送这次提交时，git 服务端钩子就会起作用，将提交的代码更新到合适的地方。

如果提交信息中没有特定的 命令 ，那么这就是一次普通的推送而已。

在本例中，钩子所做的事情就是将 src/ 文件夹中的所有代码更新到服务端程序中。

serverctrl.git

这个仓库是空的，永远不会有内容。通过在提交信息中包含特定的 命令，git 服务器钩子会对我们的服务端程序进行给定的操作。

三、使用钩子重启服务端程序

OpenResty 的进程控制

使用 nginx 自己提供的 -s 参数来控制服务端程序：

nginx -s [stop|quit|reopen|reload] -p /path/to

不带 -s 参数，就是 start 功能了：

nginx -p /path/to

命令

serverctrl 是个空项目，不可能有任何内容。因此我规定提交信息中直接写操作命令即可。

要控制服务端程序重启，只需要进行这样的提交和推送&