更加通用的Hexo多端部署原理及实现，适用于各种系统之间

本文推荐在作者的个人博客网站阅读：shenying.online

一、故事背景

故事发生在大学上学期间（而不是寒假）。上学期间，宿舍条件极其恶劣，半夜断电、空间狭小。我们大学垃圾条件使用游戏本的种种弊端被无限放大：游戏本电源适配器极其臃肿，不插电的情况续航堪忧（难以超过两个小时），并且由于其结构上的臃肿，在狭小的宿舍空间每次移动、打开犹如小平房开拖拉机。

将游戏本带去图书馆学习就更是天方夜谭，在此之前我也买了一个MatePad的平板，但是平板的使用场景对一个计科学生来说也实在有限。

于是，我用在学校做临时监考工作挣的钱入了一台MacBookAir（二手只要3k左右）。与此同时，我也预知了我即将支付不起博客网站巨额服务器费用的未来，未雨绸缪将博客迁移到了Hexo框架上，从此再无数据担忧。

我在我的MacBook上第一次部署了Hexo框架，并且由于在学校的主力机是Mac，从来没有想过在我的游戏本（也就是Windows系统）上部署Hexo框架会怎样。或者说，我从来没有考虑过移植的问题。

事情的转机从我的寒假生活开始。寒假回到家中，我的ROG魔霸新锐2023游戏本再次启动（没错我就是故意写全了得瑟的😁）。之前的缺点（笨重、移动续航堪忧）瞬间不再是缺点！在家里我的游戏本也是直接化身游戏主机站桩输出，不再需要频繁移动使用。于是我将可怜的MacBook抛到一边，低刷低配的低能MacOS一边去，Windows万岁。

直到一段时间后我又开始写Hexo博客，习惯了Wordpress网页端后台直接书写博客的我一时间竟不知道如何在我的Windows上写博客。我看了几篇博客：Hexo从Mac到Windows。我本来以为这样就能解决了，抄作业嘛多简单~

结果就是，我看了好几篇类似的Mac迁移Hexo到Windows的博客，在我的电脑上按照相同的步骤最终都会在同一个步骤报错。报错！报错！还是报错。

尝试过和人机ChatGPT老师交流，无果ed。

谁知这事儿就这样撂下了，我也懒得研究了，几乎有半个寒假，我每次想在我的shenying.online上发布博客都是将阵地转移到Mac上操作。就这么麻烦的事儿我干了一个寒假，就因为跟着上面说的博客做爆了错没有成功移植（要知道我寒假主力机一直是Windows的ROG，你可以想象我正在用windows写Markdown格式的博客，但是到了发布到Gitpage的时候却不得不打开Mac再复制过去发布一遍）。

直到2月12日事情才迎来了转机，我实在无法忍受这种写博客的割裂感了！我要像Hexo(骇客)一样写博客！我不能忘记老祖宗传下来的编程教养：优雅。这么粗鲁的事情不能再干下去了，一点儿也不Hexo。

接下来就是我自己弄懂的Heox博客部署原理以及多端部署的核心思路。

二、Hexo 文件结构解读

想知道Hexo如何多端部署，先要知道Hexo是怎么工作的。首先我们来看看Hexo框架的文件结构：

看好了，别眨眼。这里的node_modules是node的用到的库，系统会根据你安装的主题啊之类的自定义自动生成，不用太关注他（意思是弄丢了也没事儿，毕竟不是核心数据）。

public是你用hexo g后生成的静态文件。相应的hexo clean会删除他。

scaffolds也是Hexo初始化会自动生成的默认文件，你写文章不会影响里面的文件所以不用管他。

source就非常重要了，我们重点来看一下。可以看到，里面存放的是最核心的文件，也就是博客网站的生命，博客文章的.md格式文件，草稿，还有一些主题生成的文件，这里以我常用的主题redefine为例，个别文件可能不一样。

themes文件夹里没什么重要的文件，不用管。

这里就要谈一下Hexo的工作机制了，Hexo本质上还是类似Vue脚手架那一套的前端框架。你可以理解为你在本地编写了source中的文件，这时候你想要发布到网页上去，Hexo就会帮你项目打包到public文件夹中并成为一个静态的前端项目，然后将public文件夹中的文件部署到Gitpage。

发现没有，这里的public的功能很像你写一个程序，编译成了exe。你把exe发送给别人让别人直接执行。

并且这里的source相当于是你的元数据，类似于数据库一样至关重要的存在。

接着说说这里的_config.yml，这是你的网站的一些配置，也就是个性化的自定义文件。如果你使用的主题，就会有主题对应的_config.yml来配置你的主题的一些个性化设置，例如这里有两个主题：config.landscape.yml和config.redefine.ym。

package.json中存放着你用npm下载的包的信息，你可以理解为npm是一个应用商店，这就是应用商店的应用列表。我看的教程中就是告诉我把原来电脑的package.json拷贝过来然后在根目录npm install。结果我按着操作，每次安装都会抱一堆警告和错误。

所以，这个文件我们也不需要。

2.1 需要的文件

综上所述，我们其实只需要关注我们博客网站的核心文件即可，我建议将他们专门备份到一个代码仓库：

没错，就是他们。你看我多谨慎。想想如果我还在使用Wordpress博客来备份还需要备份什么数据库，如果用Hexo静态博客框架就只需要把你的文章的.md文件和站点配置文件_config.yml全塞进一个仓库就行了，多方便。

当然还有一种更加优雅的方案：创建一个名为Hexo的分支，存放你的Heox本地配置文件。网上都能找到教程，点我跳转到其中一篇。

由于Hexo会将source经过框架内部的处理和美化最终生成一个public部署到Gitpage，而public又是有别于source的。比如，你好世界.md这篇文章在public中找到后已经变成了你好世界.html了。所以Github的博客托管仓库中是没有我们的source的，也找不到那些文章的.md的markdown文件。它都变成html格式了，你还怎么玩？

这些重要文件只会在你的本地计算机上，所以一定要自己及时备份起来以防后患（说不定哪天你的电脑就自己偷偷喝咖啡了呢~🔪）。

完成这些文件的备份，工作就很机械了。我的终极完美适配的思路是：按照原来你部署的方式，老老实实地从零开始部署。冷静地打开你的主题的官方文档，老老实实地把主题包括每一个插件自己安装上。

没错，你没有听错，终极的方案就是这么朴实无华。

然后的然后，把source和config相关的文件一五一十的替换。在Gitpage或者说Github的博客托管仓库中创建一个新的Branch，BranchName（分支名）就见仁见智了，比如我在Windows写博客的时候，用windows这个branch。

然后就是很是很重要的一点（我已经不知道说了多少个然后了，果然连接词还是得多学啊，Then，After that什么的，哈哈）。你最后总要hexo d然后把你的静态文件托管上去的吧，所以别傻傻的把_config.yml完全替换过去。你总得把里面的branch名字改成你新创建的branchName吧。

三、协同方案分析

完成了上述，你已经有一个专门分支了吧？我的建议是每个电脑一个分支。我来举个例子，比如你最新的进度是在Mac上写的，并且分支名是main（github由于种族问题已经将默认分支master改成了main了），这个时候你想在windows电脑上写一篇文章，然后你就写，写完之后hexo clean、hexo g、hexo d一步没落下，最终静态文件被托管到了branch windows下。

这个时候你可能又回到了mac电脑上了，就需要同步一下博客的进度。所以你需要将main分支和windows分支同步即可。

具体的，如果长期在windows上写博客，并且懒得更新原来的分支了，你可以在Gitpage将默认分支改为windows（非必需），将Gitpage的渲染的分支改为windows（必须）。

这里可以使用本方案：

下面的描述很人机因为是问的ChatGPT，不问DeepSeek是因为deepSeek服务器被打废了。

1.切换到 main 分支：

git checkout main

2.拉取 main 分支的最新更新：

git pull origin main

3.切换到 wind 分支：

git checkout wind

4.将 main 的更新合并到 wind：

git merge main

这样，wind 分支就会包含 main 分支的最新内容。如果有冲突，你需要手动解决冲突。

5.推送合并后的 wind 分支：

git push origin wind

四、补充一个更加全面的备份方案

前面不是说了嘛，hexo不会将本地的文件上传到Github博客的仓库，那如果这个本地文件丢失了岂不是糟糕？上面也提到一种最简单粗暴的备份方案，将source和config直接扔到一个仓库中。

但是，这种方案在分支备份大法前就显得不那么优雅了。

因为在本地的hexo项目中无法使用git命令，所以我们要将远程的仓库克隆下来方便我们添加一个新的分支hexo，并在hexo中专门存放我们的本地项目文件。注意，之前提到的main分支或者说默认分支都是存放的hexo打包好的静态页面文件，我就不多提了。

具体的方法：

# 1.克隆远程仓库
git clone [e-mail]:CCCCOOH/CCCCOOH.github.io.git（根据自己的仓库来决定）# 2.cd到克隆下来的仓库目录下（这里省略，根据你的文件目录来），然后创建一个新的分支hexo
git branch hexo# 3.将分支切换到hexo
git checkout hexo# 4.删除原来的文件（单独留下.git），将本地的文件（建议删除public）拷贝到目录下。
# 5.最后将分支推送到远程(Githhub仓库)
git add .
git commit -m '添加了hexo分支用于存放本地文件'
git push origin hexo

这里讲给git小白听。在第四步中你创建了hexo后，hexo默认会复制默认的分支，所以文件夹中的文件和默认分支一样。我们不需要这些文件，将他们删除，然后再拷贝你的本地文件到这个目录下并推送到远程就好了。

附一张备份文件目录的图。