问题背景
在迁移到新的机器设备时，如何同步之前已有的 GitHub Pages 文章？又如何在原有内容的基础上，继续更新文章内容？
解决方案
使用 Git 。
首先，对于搭建的 GitHub Pages ，其本身就要求所有页面资源存储于 username.github.io 的仓库下。所以，Git 本身就已经帮我们的文章资源做出了一些管理，在此基础上，我们可以继续利用这个仓库来管理我们的 hexo 资源。
对于这个仓库的 master 分支来说，其内容均是页面部署所需的资源（GitHub Pages 指定部署目录为 root 即可），与 hexo 目录下的目录结构差异较大，所以用同一个 master 来存储，实践上就不合理。同样地，master 分支下的内容可以认为是部署页面所需的所有资源，而 hexo 目录下的很多内容，并不是部署时所必须的，所以逻辑上来说，也不应该将两部分资源合并在一起。
综上，我们可以使用 Git 的分支来管理两部分资源。可以建立一个名为 hexo 的分支，将hexo相关的内容直接放到这个分支上，将部署资源(即 hexo g 生成的 public 目录内容放到 master 分支上。
这样一来，即可很灵活地写博客、部署博客、迁移博客了。当迁移到新的设备上时，先将仓库克隆下来，再切换到 hexo 分支，将目录作为正常的hexo文件目录即可。需要注意的是，不要修改本地的 master 分支内容，因为正如上面所述，其内容全部是 hexo 分支执行部署之后生成的 public 下的内容。如果本地修改，就会在hexo部署之后，使得本地与远程内容不一致问题。
更多地，你需要尽可能让仓库内容精简些，所以建议在 hexo 分支下添加 .gitignore 来避免一些自动生成的内容被提交。分享下目前在用的 .gitignore:
1 | # For hexo data |
以上的方式，是将部署与生成分开的做法，当然，也可以直接用 master 来管理 hexo 目录内容，这时就需要在远程指定部署目录为 public，当然，此时也就不用在 .gitignore 中显式指定忽略 public 目录的版本控制了。同时，这种情况下可能要注意下配置文件等的相关路径问题，以避免目录层级导致的资源访问问题。
2022.08.22 补充
事实上，master 分支的内容都是 hexo 分支执行部署命令自动生成并提交到 GitHub 的，对于自动生成的内容，创作者并不需要额外关注，只需要关注“源码文件”即可。也就是说，创作者在创作环境下、新的环境下，都只需要拉取同步远程的 hexo 分支即可，因为 master 分支的内容永远会被自动生成及覆盖。当然，对于 GitHub 提供的 gh-pages 分支，也是类似的道理。