一、Github Action 介绍
Github Action 是由 GitHub 在 2018 年 10 月推出的一款强大的 CI/CD 服务。CI/CD 实际上涵盖了三件重要的事情，分别是 “持续集成（Continuous Integration）”、“持续交付（Continuous Delivery）” 以及 “持续部署（Continuous Deployment）”。由于 “持续交付” 和 “持续部署” 的英文缩写相同，所以这三件事通常缩写为 CI/CD。
二、Hexo 部署与 Github Action 的优势
每次部署 Hexo 时都需要运行一系列指令，随着文章数量的增加，编译时间也会越来越长。而借助 Github Action，我们只需在完成博客的编写或修改后，将改动推送到远程仓库即可。后续的编译部署工作可交由 CI 来完成。对于看过相关部署教程的小伙伴来说，这种持续部署的操作方式会带来极大的便利。
三、教程常量声明
为避免混淆各种常量名，我们将使用特定的常量名来指代一些名词。建议读者在阅读教程时直接使用这些常量名，并在最后进行逐一搜索替换。
常量名及释义如下：
[Blogroot]：本地存放博客源码的文件夹路径。
[SourceRepo]：存放博客源码的私有仓库名。
[SiteBlogRepo]：存放编译好的博客页面的公有仓库名。其中，“Site” 在教程中会根据不同的平台替换成 “Github”、“Gitee”、“Coding”。
[GithubBlogRepo]：Akilarlxh.github.io。
[GiteeBlogRepo]：akilar。
[CodingBlogRepo]：akilar/akilar。
[SiteUsername]：用户名。同样，“Site” 在教程中会根据不同的平台替换成 “Github”、“Gitee”、“Coding”。
[GithubUsername]：Akilarlxh。
[GiteeUsername]：Akilar。
[CodingUsername]：akilar。
[SiteToken]：申请到的令牌码。“Site” 在教程中会根据不同的平台替换成 “Github”、“Gitee”、“Coding”。
[GithubToken]：15076c8eb9c874sad676bc9bfb13sadw86babf2。
[GiteeToken]：f57acasdadgar4578603adas5d8w79bb。
[CodingToken]：a4e45daf78as1f2670dcbbcfd5as7d8asd8cd66a77。
[GithubEmail]：与 github 绑定的主邮箱，推荐使用 Gmail，例如：akilarlxh@gmail.com。
[TokenUser]：Coding 配置特有的令牌用户名，如：RAxDiobbRi。
我们可以在记事本中逐个记录这些常量，方便后续进行替换。例如：
[Blogroot]：E:\Blogroot。
[SourceRepo]：Akilarlxh/Hexo-blog-source。
四、Github Action 使用教程
获取 Token：
为了确保 Github Action 在进行持续部署时拥有足够的权限来执行 hexo deploy 操作，我们需要先获取 Token。如果博主在 Github、Gitee、Coding 等平台都部署了静态页面，那么就需要获取这三个平台的 Token。
Github：访问 Github，点击头像（右上角）->Settings->Developer Settings->Personal access tokens->generate new token。创建 Token 时，名称可以随意设置，但必须勾选 repo 项和 workflows 项。
Gitee：访问 Gitee，点击头像（右上角）-> 设置 -> 私人令牌 -> 生成新令牌。
请注意，Token 只会显示一次，之后将无法查看，所以务必确保已经记录下了 Token。如果忘记了，就只能重新生成并重新配置。
创建存放源码的私有仓库：
我们需要创建一个用于存放 Hexo 博客源码的私有仓库 [SourceRepo]。这在 Win10 的 Hexo 博客搭建教程中有所提及。为了保持教程的连贯性，在此再次说明。
创建完成后，将博客的源码推送到这个仓库。首先获取远程仓库地址，这里 SSH 和 HTTPS 方式均可。SSH 在绑定过 ssh key 的设备上无需再输入密码，而 HTTPS 则需要输入密码。不过，SSH 偶尔会遇到端口占用的情况，大家可以根据自己的情况进行选择。
选择私有仓库的原因是在后续的配置中会用到 Token，如果 Token 被盗用，别人可能会肆意操作你的 github 仓库内容。为了避免这种风险，我们选择将博客源码闭源。
配置 Github Action：
在 [Blogroot] 新建一个以 “.” 开头的.github 文件夹。然后在.github 文件夹内新建 workflows 文件夹，再在 workflows 文件夹内新建 autodeploy.yml 文件。
在 [Blogroot]/.github/workflows/autodeploy.yml 文件中输入以下内容：

当有改动推送到 master 分支时，启动 Action

name: 自动部署
on:
push:
branches:
– master #2020 年 10 月后 github 新建仓库默认分支改为 main，注意更改
release:
types:
– published
jobs:
deploy:
runs-on: ubuntu-latest
steps:
– name: 检查分支
uses: actions/checkout@v2
with:
ref: master #2020 年 10 月后 github 新建仓库默认分支改为 main，注意更改
– name: 安装 Node
uses: actions/setup-node@v1
with:
node-version: “12.x” #action 使用的 node 版本，建议大版本和本地保持一致。可以在本地用 node -v 查询版本号。
– name: 安装 Hexo
run: |
export TZ=’Asia/Shanghai’
npm install hexo-cli -g
– name: 缓存 Hexo
uses: actions/cache@v1
id: cache
with:
path: node_modules
key: ${{runner.OS}}-${{hashFiles(‘**/package-lock.json’)}}
– name: 安装依赖
if: steps.cache.outputs.cache-hit!= ‘true’
run: |
npm install –save
– name: 生成静态文件
run: |
hexo clean
hexo generate
– name: 部署 #此处 master:master 指从本地的 master 分支提交到远程仓库的 master 分支，若远程仓库没有对应分支则新建一个。如有其他需要，可以根据自己的需求更改。
run: |
cd./public
git init
git config –global user.name ‘${{ secrets.GITHUBUSERNAME }}’
git config –global user.email ‘${{ secrets.GITHUBEMAIL }}’
git add.
git commit -m “${{ github.event.head_commit.message }} $(date +”%Z %Y-%m-%d %A %H:%M:%S”) Updated By Github Actions”
git push –force –quiet “https://${{ secrets.GITHUBUSERNAME }}:${{ secrets.GITHUBTOKEN }}@github.com/${{ secrets.GITHUBUSERNAME }}/${{ secrets.GITHUBUSERNAME }}.github.io.git” master:master
#git push –force –quiet “https://${{ secrets.TOKENUSER }}:${{ secrets.CODINGTOKEN }}@e.coding.net/${{ secrets.CODINGUSERNAME }}/${{ secrets.CODINGBLOGREPO }}.git” master:master #coding 部署写法，需要的自行取消注释
#git push –force –quiet “https://${{ secrets.GITEEUSERNAME }}:${{ secrets.GITEETOKEN }}@gitee.com/${{ secrets.GITEEUSERNAME }}/${{ secrets.GITEEUSERNAME }}.git” master:master #gitee 部署写法，需要的自行取消注释

注意，最后一行的 master:master 指从本地的 master 分支提交到远程仓库的 master 分支，需要根据实际情况进行调整。本地分支可以在 git bash 中查看，线上分支可以在提交仓库中查看。由于 “政治正确” 的原因，github 在 2020 年 10 月将默认分支改为 main。而 git 软件在本地默认创建的分支依然是 master，所以若线上仓库默认分支是 main，这里应该写成 master:main，表示从本地的 master 推送到远程的 main。
之后需要自己到仓库的 Settings->Secrets->actions 下添加环境变量，变量名参考脚本中出现的，依次添加。例如，如果需要部署在 github page 上，那么脚本中必要的变量为 GITHUBUSERNAME、GITHUBEMAIL、GITHUBTOKEN，因此需要添加这三条变量。变量具体内容释义可以查看本文开头。
重新设置远程仓库和分支：
删除或者先把 [Blogroot]/themes/butterfly/.git 移动到非博客文件夹目录下，原因是主题文件夹下的.git 文件夹的存在会导致其被识别成子项目，从而无法被上传到源码仓库。
在博客根目录 [Blogroot] 路径下运行以下指令：
git init #初始化
git remote add origin git@github.com:[GithubUsername]/[SourceRepo].git #[SourceRepo]为存放源码的 github 私有仓库
git checkout -b master # 切换到 master 分支，

2020 年 10 月后 github 新建仓库默认分支改为 main，注意更改

如果不是，后面的所有设置的分支记得保持一致

添加屏蔽项：
因为能够使用指令进行安装的内容不包括在需要提交的源码内，所以我们需要将这些内容添加到屏蔽项，表示不上传到 github 上。这样可以显著减少需要提交的文件量并加快提交速度。
打开 [Blogroot]/.gitignore，输入以下内容：
.DS_Store
Thumbs.db
db.json
.log node_modules/ public/ .deploy/
.deploy_git*/
.idea
themes/butterfly/.git

如果不是 butterfly 主题，记得替换最后一行内容为你自己当前使用的主题。
之后再运行 git 提交指令，将博客源码提交到 github 上。牢记下方的三行指令，以后都是通过这个指令进行提交。
git add.
git commit -m “github action update” #引号内的内容可以自行更改作为提交记录。
git push origin master

2020 年 10 月后 github 新建仓库默认分支改为 main，注意更改

此时，如果你的主题文件夹已被正常上传，并且你也添加了主题文件夹下的.git 文件夹的屏蔽项。那么你可以考虑把第二步移走或删除的.git 放回来，用作以后升级。（不禁让人怀疑真的有人会用这个方式来升级吗）
查看部署情况：
此时，打开 Github 存放源码的私有仓库，找到 action。
根据刚刚的 Commit 记录找到相应的任务。
点击 Deploy 查看部署情况。
若全部打钩，恭喜你，现在可以享受自动部署的快感了。
五、可能遇到的 bug
Unknown block tag:”tagname”：
如果在 github action 部署时遇到 “unknown block tag: “tagname”” 这样的报错，说明可能没有正确上传主题文件夹，也可能遇到安装依赖或生成页面失败的情况。
请按照以下思路逐一排查：
是否将 node_modules 也上传到源码仓库 [SourceRepo] 了。源码仓库不需要有 node_modules 文件夹。
是否有将 [Blogroot]/themes/ 下的主题文件夹上传，例如检查 [SourceRepo] 内的 [Blogroot]/themes/Butterfly 是否为空文件夹。为了能够正常编译页面，源码仓库需要有 [Blogroot]/themes/Butterfly 文件夹及它所包含的主题文件内容。
为了避免这两点，需要添加 git 屏蔽项。通过给.gitignore 添加屏蔽项解决。打开 [Blogroot]/.gitignore，输入以下内容：
.DS_Store
Thumbs.db
db.json
.log node_modules/ public/ .deploy/
.deploy_git*/
.idea
themes/butterfly/.git

若是遇到添加屏蔽项，但是还是无法正常上传主题文件夹的情况。请先将本地源码中的 themes/butterfly 文件夹下的.git 文件夹删除。然后将 butterfly 文件夹移动到别的目录下。然后 commit 一次。接着将 butterfly 文件夹移动回来，再 commit 一次。
变量名称问题：
部分不愿意使用教程给出的变量名的人可能会遇到未知 bug。此处给出官方的命名规则：
以下规则适用于密码名称：
密钥名称只能包含字母数字字符（[a-z]、[A-Z]、[0-9]）或下划线 ()。不允许有空格。 密钥名称不得以 GITHUB 前缀开头。
密钥名称不能以数字开头。
密钥名称不区分大小写。
密钥名称在所创建的级别上必须是唯一的。
spawn failed：
如果遇到 “spawn failed” 报错，一般是因为涉及到部署地址的配置项有误。
首先排查你在 [Blogroot]_config.yml 的 deploy 配置项是否按照上文配置 deploy 项中的步骤正确组装配置链接。
其次排查 [Blogroot].github\workflows\autodeploy.yml 中各个关于仓库链接的配置内容，注意按照注释指引检查空格、分支等。
更多可能的因素和解决方案可以参考 @洪哥 HEO 写的方案：Hexo 错误：spawn failed 的解决方法。
分支问题：
本地分支和线上分支不一致可能导致总是提交不上。
注意观察 autodeploy.yml 文件中：
git push –force –quiet “https://${{ secrets.GITHUBUSERNAME }}:${{ secrets.GITHUBTOKEN }}@github.com/${{ secrets.GITHUBUSERNAME }}/${{ secrets.GITHUBUSERNAME }}.github.io.git” master:master

末尾的 master:master 指从本地的 master 分支提交到远程仓库的 master 分支。需要根据实际情况进行调整。本地的分支可在 git bash 中查看。线上的分支可在仓库查看。比如本地默认分支是 master，线上默认分支是 main，应该改成 master:main。
会遇到这类问题，一般是有同学直接全局替换 master 为 main 导致。
六、后记
可能有同学会问，Github action 有什么用呢？这不就是从 hexo cl && hexo g && hexo s 的三件套变成了 git add.,git commit -m “commit content”,git push 三件套吗？
实际上，Github action 的最大作用在于进一步提高速度和便携性。首先，配置要求提交源码，这使得萌新小白无需再靠本地不断新建压缩包来备份源码。借助 git 的版本管理，不管怎么改都可以快速回滚。其次，git 提交是增量更新，每次只提交新增或者删改的内容，而 hexo deploy 是在本地每次重新生成所有静态文件以后再整个提交。Github action 能为我们节省大量时间，把最耗时的 hexo generate 和 hexo deploy 的工作丢给 CI 处理。让我们能够专心撰写博客内容，而不是 “水文 3 分钟，提交半小时”。
七、发散思维
由于 Github action 只要监测到 master 分支有所变动就会启动部署，所以手机用户可以在网页 Github 上进行小幅修改，例如修改错别字、调整布局之类的。保存后也会启动 Github action，从而将内容部署到网页上。