GitHub的post-receive 钩子中有一个可以使用reync或scp的选项。这是另外的一种选择——特别是当你的应用需要构建时（GitHub限制了可能的命令）——是使用post-receive 钩子来触发，然后使用-f选项可以检查出从GitHub的代码库的应用程序服务器上的脚本和运行其他一些必要的命令。这个时候，自动化部署开始变得复杂起来，我们不得不使用下一套工具来更好的完成。
从 GitHub 直接自动部署GitHub 有它自己的文档来自动化部署到集成平台，这里包括一些托管提供商。
老实说，大部分文档都有些错误，不准确或者没有起到作用， 在一些主流的主机提供商那儿，我做了一些搜索链接到官方文档，对于其他一些提供商，我建议你使用 post-receiveor 持续集成的方法：
持续集成(CI)服务有许多无数的能够查看 GitHub 项目回购变更协议的应用服务，不仅能够为你部署，而且能够执行其他功能，诸如为你运行测试和构建过程。
一旦你移动到一个新的和更复杂的实例时，我们可以使用 CI
自动化构建项目过程。首先，拉伸一个存储库的 Master 分支，然后触发一个运行构建的 bash 脚本，并且部署流程以及对微博更新。CI 与 web 服务能够在同一台服务器上或者在不同的服务器上运行，这一切都取决于你的偏好。
让我们迅速一览其最受欢迎的部分吧。
Jenkins你需要搭建你自己的 Jenkins 服务器，这意味着你可以完全地控制它，但必须要对它进行维护。幸运的是，它提供了多平台支持，如果你只是想要先简单尝试一下的话，这些支持也包括了 Docker。
Jenkins 使用插件实现了自己的大部分功能，并且由于其年代久远、开源的性质以及普及度很广，它拥有很多的插件。例如，有一些 Git、GitHub 和 Twitter 的相关插件。
Jenkins 需要大量的配置，而且有时，若想要将你需要的指令组合到一起来构造你所需的工作流程，可能需要大量的研究。
Jenkins 的详细介绍：请点这里
Jenkins 的下载地址：请点这里
此外，在 GitHub 文档中，使用 GitHub 的 Travis 集成指令已经过时。现在，它更简单：阅读找出更多的 Travis 文档。
Travis 不需要任何主机与服务器设置，因此你无需投入太多的精力，就可以保持和试用CI，这是一个很好的起点。不过，扩展超出（综合）默认的集成将涉及到一些额外的配置工作。比如，微博请求对 webhooks 的访问。
在回购中，你会注意到 Travis-- 特别是在配置自己的文件中，它有一个习惯，就是更新太慢。当你本身没有对 Travis 服务器进行访问时，那么这些问题就难以解决。
其他商业服务持续集成已经日益流行了，所以已经有了非常多的新的服务和应用程序 – 很多是通过你可能已经在使用的工具的创作者释出的，并且将很和谐的融入到现有的工具链和工作流程当中。这里有些例子：
总结
希望这篇简要的介绍已经为你阐明了关于这种部署方式是如何工作的一些事情。当然，我们还有很长的路来实现通过 FTP 将你的文件传到你的服务器！
如果你对上述流程有任何疑问，请在评论区中让我知晓。
GitHub 教程系列文章：