我把这些选项划分到不同的工具集当中，这些集合包括自动运行测试，以及拉取代码部署到服务器上等等。
为何要这样做？有了这些自动化过程的运行，你和你的团队就可以只关注单纯的编码以及代码的合并，而不是每次build的时候都要花费几个小时去重复的做部署这样的事情。
自动化的缺点自动化部署变化的主要问题是变化会自动地被部署。你必须信任你的团队以及他们写的代码。这就是为什么自动化部署和自动化测试的搭配成为典型，而下面提供的工具也反映了这一点。
来源于此文作者的更多内容当然，这同样意味着仍和小问题也一样地被快速修复。自动化应该与沟通配合。如果推送到一个库的主分支会引发住建，需要明确，当这种情况发生时谁去做这件事情。
一个自动化的初始设置过程可能需要一些时间。因此权衡你的团队或者工作流程是否真正的需要它是一件重要的事情。把你们花在测试和部署新的构建上的时间加起来——如果是每次超过几分钟，那么它是值得的。
Git Hooks（钩子）
Git内置了一套拓展框架叫做钩子（）用来处理自动化部署，并且这些钩子一般在被特定的Git事件(certain points)触发后被调用在我们的第一端口用来处理任务。钩子可以被分为服务器端钩子与客户端钩子。
服务器端是用于监听网络操作的事件 ——比如，当存储库接收推送后。而客户端挂钩的触发是因为开发者进行了操作，如提交和合并。
这是在Git文档中hooks的完整列表（）。我会注释一对情侣在这里让你开始。希望这能让你在自己当前手动部署的项目工作流程中中变得非常有用。Hooks可以在任何语言的项目部署中运行，强大而灵活。
pre-commit此这个钩子运行在其他所有钩子之前，并且在更改提交之前。可以用来在提交前检查代码错误。
我们在这里写一个JavaScript的小项目说明（当然，我故意留了你可以找到的bug）。
重命名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
添加缺少的分号后重新提交，不在报错。
post-receive
当推送远程Git仓库完成时，服务器端的该钩子触发。在这个例子中，我们推出一个简单的网站的最新版本到你的Web服务器目录，实际上是一个（最基本的）部署。
我有一个现有的网站包含有一个index.html页 - 以及我们在后面的例子将使用的其他网页。你也可以创建自己的，使用在这里设立仓库。
克隆仓库，通过指定--bear标记来创建一个只包含版本控制信息的存储库，而不是我们的代码仓库：
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
注意：这些路径是基于Ubuntu环境下完成，所以记得要改变路径，以满足你的路径。
该命令将推出当前仓库到定义的工作目录，但没有任何版本控制数据。
更改文件属性使之可执行：
chmod +x post-receive
小贴士：这些位置与Ubuntu的安装路径相关，所以一定记得要改变路径，以满足您的设置。该命令将检查当前的存储库到定义的工作目录，但没有任何版本控制数据。
将文件添加可执行的权限：
chmod +x post-receive
在你的本地端，像平时一样克隆这个库，使用你选择的工具，并添加一个新的远程的实时服务器（记得更改服务器的详细信息到你的Web服务器和用户的详细信息）：
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文件夹内啦。
如果你使用的是自己的Git仓库，你可以把它配置在同一台服务器上的应用，并实现自动化部署。如果你使用的是GitHub上或其他外部Git的服务，那么这个钩子还没有完全自动化，但它已经降到了一步。这可以进一步简化。