0x00 背景 使用 Hexo + Github Pages 搭建博客后，每次更新文章需要使用 hexo d -g 会在本地生成 public 静态博客网站和向 Github 推送的 .deploy_git 文件夹。 .deploy_git 文件夹内容和 public 文件夹一致，但多了 Github 博客项目的仓库信息与提交信息。最终， .deploy_git 文件夹内的全部内容被推送到 Github 仓库中，由 Github Pages 服务完成静态网站的解析。 当切换工作环境后，需要重新安装 Nodejs 以及配置 Hexo 和它的依赖。而且每次更新文章后，都要 hexo d -g 手动部署。这样多次重复的工作非常低效，因此结合现在非常流行的 CI/CD 概念和工具，可以为 Hexo + Github Pages 博客集成 Travis CI 自动部署的能力。当推送博客仓库到 Github 后，由 Travis 自动获取当前 commit 并进行构建，把生成的静态网站推送到 Github Pages 分支。 0x01 理解 Hexo 的自动化部署 下图是 Hexo 手动部署的流程，hexo-blog 可以是本地一个项目，也可以是 Github、Gitlab 等仓库，本地配置好 Hexo 环境后，由 ① 触发部署，将本地生成的静态博客网站 .delpoy_git 推送到 Github 的静态博客仓库中。 当引入 Travis 后，整个流程变成了下图所示的流程。hexo-blog 项目必须是一个 Github 仓库了，当有文章更新，本地由 ① 触发，把 Hexo-blog 的源码推送到 Github，剩下的工作由 Travis 完成：获取 Github hexo-blog 仓库中最新的 commit，运行我们定义的 .travis.yml 并把生成的静态博客网站 .deploy_git 推送 Github 静态博客仓库 xxx.github.io。 注意，这里要区分 Github 中的两个仓库：静态 blog repo 和 Hexo blog repo。前者是博客网站的静态网站项目，由 Github Pages 托管和解析；后者是 Hexo 项目，前者的内容是由后者生成的。 0x02 如何配置自动化部