GitHub, and the Git version control system it’s based on, are fantastic tools for managing and collaborating on projects – code-based or otherwise.

In this article, we’ll look at options for making Git and GitHub projects fit better into developer workflows, allowing for a smooth and hands-off deployment process.

I’ll break these options into the different types of toolsets available – which allow for options from automatically running tests and code checks to deploying your code to a server.




Why Do This?

With these automated processes up and running, you and your team can focus purely on coding, approving and merging code, rather than spending hours on deployments and repetitive tasks every time a new build or change is ready.



Disadvantages of Automation

The main problem with automatically deploying changes is that changes are automatically deployed. You have to trust your team and the code they write. This is why automatic deployment is typically paired with automated testing, and the tools presented below reflect this.

More from this author

Of course, it also means that any small issues are equally as quick to fix. Automation should be paired with communication. If pushing to a repository’s master branch can trigger live builds, it needs to be clear when this happens and who can make it happen.

The initial setup of an automation process can take some time to get right. It’s important to weigh up whether or not your team or workflow really needs it. Add up the amount of time you spend on testing and deploying new builds – and if it’s more than a few minutes each time, then it’s worth it.






Git Hooks

Git has a suite of in-built hooks that can be used for automation, and these are often our first port of call for processing tasks after particular Git actions. These are divided into server- and client-side hooks.

Server-side hooks are for events such as listening to network operations – for example, when a repository receives a push. Client-side hooks are triggered on actions that occur on a developer’s machine, such as commits and merges.

There’s a full list of hooks in Git’s documentation. I’ll look at a couple here to get you started. Hopefully you’ll start to see how they may be useful in your own projects and current (manual) workflows. The hooks are files that can contain commands in any language the host system can run, allowing for a lot of power and flexibility.


This client-side hook runs before any other hook, and before any changes are committed. It’s a perfect place to run tests or other checks on your code.

Let’s add some basic JavaScript to our small project (and yes, there is an intentional mistake here):

document.onload = function() {
    alert("Hello World")

We’ll use JSHint to check the JavaScript for errors. (You can find installation instructions here.)

Rename hooks/pre-commit.sample to hooks/pre-commit, and change the contents of the file to this:

#!/bin/shjshint index.js

Try to commit the changes:

git commit -m "adding Javascript file"

You’ll see the following error message:

index.js: line 5, col 25, Missing semicolon.1 error

Add the missing semicolon and try again. The commit will now progress without any problems.


This server-side hook triggers when a push to a remote Git repository completes. In this example, we checkout the latest version of a simple website into our webserver directory, effectively a (basic) deployment.

I have an existing website that consists of an index.html page – along with some other pages that we’ll use in later examples. You can create your own or use the repository set up here.

Clone the repository, specifying the --bare flag to create a repository that only consists of version control information and not our code base:

git clone --bare https://github.com/sitepoint-editors/GitHub-Auto-Deploy.git GitHub-Auto-Deploy.git

Now we’ll create our hook:

cd GitHub-Auto-Deploy.git/hooksvi post-receive

Add these lines to the file:

#!/bin/shgit --work-tree=/var/www/html --git-dir=/var/repo/GitHub-Auto-Deploy.git checkout -f

Note: these locations are relevant to an Ubuntu installation, so remember to change paths to suit your setup.

This command will checkout the current repository into the defined working directory, but without any version control data.

We need to make the hook executable:

chmod +x post-receive

On your local machine, clone the repository as normal, using your tool of choice, and add a new remote for the live server (remember to change the server details to your webserver and user details):

git remote add prod ssh://user@domain.com/var/repo/GitHub-Auto-Deploy.git

To deploy to our production server instead of the repository, enter:

git push prod master

If you look inside the var/www/html folder, you’ll find the index.html file automatically copied into your web folder.

If you’re using your own Git repository, you can have it located on the same server as your application, and deployments are now automated. If you’re using GitHub or another external Git service, then this hook has not completely automated your workflow, but rather has reduced it to one step. This can then be simplified further.

One option is using rsync or scp commands in the post-receive hook on GitHub. Another option – especially if your application needs a build process before going live (GitHub limits possible commands) – is to use the post-receive hook to trigger scripts on your application server that checks-out your code base from GitHub (with the -f option) and runs any other necessary commands. This is starting to get complicated, which leads nicely to our next set of tools.

Git Hooks(钩子)

Git内置了一套拓展框架叫做钩子(http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)用来处理自动化部署,并且这些钩子一般在被特定的Git事件(certain points)触发后被调用在我们的第一端口用来处理任务。钩子可以被分为服务器端钩子与客户端钩子。

服务器端是用于监听网络操作的事件 ——比如,当存储库接收推送后。而客户端挂钩的触发是因为开发者进行了操作,如提交和合并。





重命名hooks/pre-commit.sample 为 hooks/pre-commit,并进行如下测试命令,以这样的内容:

#!/bin/shjshint index.js


git commit -m "adding Javascript file"


index.js: line 5, col 25, Missing semicolon.1 error



我有一个现有的网站包含有一个index.html页 - 以及我们在后面的例子将使用的其他网页。你也可以创建自己的,使用在这里设立仓库。

git clone --bare https://github.com/sitepoint-editors/GitHub-Auto-Deploy.git GitHub-Auto-Deploy.git


cd GitHub-Auto-Deploy.git/hooksvi post-receive


#!/bin/shgit --work-tree=/var/www/html --git-dir=/var/repo/GitHub-Auto-Deploy.git checkout -f


chmod +x post-receive



chmod +x post-receive

git remote add prod ssh://user@domain.com/var/repo/GitHub-Auto-Deploy.git

git push prod master
你可以ls一下服务器的 var/www/html 目录,可以看到index.html文件已经被自动拷贝进你的web文件夹内啦。


GitHub的post-receive 钩子中有一个可以使用reync或scp的选项。这是另外的一种选择——特别是当你的应用需要构建时(GitHub限制了可能的命令)——是使用post-receive 钩子来触发,然后使用-f选项可以检查出从GitHub的代码库的应用程序服务器上的脚本和运行其他一些必要的命令。这个时候,自动化部署开始变得复杂起来,我们不得不使用下一套工具来更好的完成。

Autodeployment Directly from GitHub

GitHub has its own documentation for automating deployments to integration platforms, some of which are hosting providers.

To be honest, most of the documentation I checked out was incorrect, inaccurate or unhelpful, so I did some searching to link to official documentation on some popular hosting providers, and for any others I suggest you use the post-receive or continuous integration methods:

从 GitHub 直接自动部署

GitHub 有它自己的文档来自动化部署到集成平台,这里包括一些托管提供商。

老实说,大部分文档都有些错误,不准确或者没有起到作用, 在一些主流的主机提供商那儿,我做了一些搜索链接到官方文档,对于其他一些提供商,我建议你使用 post-receiveor 持续集成的方法:

Continuous Integration (CI) Services

There are a myriad services available that can watch your GitHub repos for changes and not only then deploy them for you, but also perform other functions such as running tests and build processes for you.

Moving to a new and more complex example, we could use CI to automate the build process of a project. Firstly, pulling the Master branch of a repository, triggering a bash script to run the build and deploy process, and then tweeting about the updates. The CI and web services could be on the same server or on different servers depending on your preference.

Let’s take a quick look at some of the most popular.


有许多无数的能够查看 GitHub 项目回购变更协议的应用服务,不仅能够为你部署,而且能够执行其他功能,诸如为你运行测试和构建过程。

一旦你移动到一个新的和更复杂的实例时,我们可以使用 CI

自动化构建项目过程。首先,拉伸一个存储库的 Master 分支,然后触发一个运行构建的 bash 脚本,并且部署流程以及对微博更新。CI 与 web 服务能够在同一台服务器上或者在不同的服务器上运行,这一切都取决于你的偏好。



You’ll need to set up your own Jenkins server, which means you get complete control, but it requires maintenance. Fortunately, it supports many platforms, including Docker if you just want to experiment first.

Jenkins achieves most of its functionality with plugins, and thanks to its age, open-source nature and popularity, it has a lot of plugins. For example, there are plugins for Git, GitHub and Twitter.

Jenkins requires a lot of configuration, and sometimes piecing together the instructions you need to construct your desired workflow can require a lot of research.


你需要搭建你自己的 Jenkins 服务器,这意味着你可以完全地控制它,但必须要对它进行维护。幸运的是,它提供了多平台支持,如果你只是想要先简单尝试一下的话,这些支持也包括了 Docker。

Jenkins 使用插件实现了自己的大部分功能,并且由于其年代久远、开源的性质以及普及度很广,它拥有很多的插件。例如,有一些 GitGitHub 和 Twitter 的相关插件。

Jenkins 需要大量的配置,而且有时,若想要将你需要的指令组合到一起来构造你所需的工作流程,可能需要大量的研究。


Again, the instructions for integrating Travis with GitHub are out of date in GitHub’s documentation. It’s even more simple now: read the Travis docs to find out more.

Travis doesn’t require any hosting or server setup, so if you’re keen to try CI without investing too much setup time, it’s a good starting point. However, extending it beyond its (comprehensive) default integrations will involve some extra config work. For example, Tweeting requires access to webhooks.

Travis has a habit of being slow to notice updates in your repos – especially in its own configuration file. These issues can then be hard to solve, as you have no access to the Travis server itself.


此外,在 GitHub 文档中,使用 GitHub 的 Travis 集成指令已经过时。现在,它更简单:阅读找出更多的 Travis 文档。

Travis 不需要任何主机与服务器设置,因此你无需投入太多的精力,就可以保持和试用CI,这是一个很好的起点。不过,扩展超出(综合)默认的集成将涉及到一些额外的配置工作。比如,微博请求对 webhooks 的访问。

在回购中,你会注意到 Travis-- 特别是在配置自己的文件中,它有一个习惯,就是更新太慢。当你本身没有对 Travis 服务器进行访问时,那么这些问题就难以解决。

Other Commercial Services

Continuous integration is increasingly popular, so there’s been a plethora of new services and applications – many released by the creators of tools you may already be using, and which will fit snugly into existing toolchains and workflows. Here are some examples:


持续集成已经日益流行了,所以已经有了非常多的新的服务和应用程序 – 很多是通过你可能已经在使用的工具的创作者释出的,并且将很和谐的融入到现有的工具链和工作流程当中。这里有些例子:

Wrap Up

Hopefully this brief introduction has clarified a few things for you regarding how this kind of deployment works. We’ve certainly come a long way from the days of FTPing your files to your server!

If you have any questions about the processes described above, please let me know in the comments.

Tags: auto deployment, continous deployment, git, git hooks, github, server side hooks


希望这篇简要的介绍已经为你阐明了关于这种部署方式是如何工作的一些事情。当然,我们还有很长的路来实现通过 FTP 将你的文件传到你的服务器!


Tags: auto deployment, continous deployment, git, git hooks, github, server side hooks