Hexo 博客多设备协同管理问题【持续更新】
优秀的 Hexo 博客多环境、多设备协同管理方案。
前面我们已经成功搭建了基于 Hexo + Github·Page + Coding·Page + Domain + VSCode + TinyPNG + PicGo + Image Host 的个人博客环境。系列博文中给出了 Hexo 新手小白如何快速搭建基于 Hexo 的个人博客进行产出。
更多 Hexo 博客框架内容,请关注博主 Hexo 博文系列:
打造沉浸式写作体验,你需要试试-Markdown-Editor
稳定快速、高效免费的图床方案-Github-jsDelivr-PicGo
前面我们提到过,hexo d 仅仅是将 Hexo 博文静态页面(public)推送到了远程仓库(Github·Page 或 Coding·Page)上以实现公共访问,而 Hexo 个人博客框架相关配置信息都存放在本地终端。如果未进行其它备份或同步处理,一旦存放 Hexo 配置信息的本地终端出现问题(如系统崩溃),那么我们便无法再维护我们的的博客了,Game Over…
所有当我们更换工作环境(公司、个人)或者原来用于搭建 Hexo 博客环境的设备需要重新更换系统,出于安全性以及灵活性考虑,我们不得不面对的一个问题就是:
如何将本地终端中的 Hexo 博客相关配置信息完美移植到新环境或保持不同创作环境同步是至关重要的。
使用 Git 解决 Hexo 个人博客多平台同步管理
关于 Hexo 博客多平台(多设备)协同管理以及更新教程网络上有很多,但对于刚刚接触 Hexo 、Git 的小白们不太友好,配置过程中容易出现各种问题,本文提到的所有配置方案均通过实际测试给出。
本文所作的主要目的:一方面作为学习记录回顾使用;另一方面适用于类似我这样的 Hexo 新手以供参考分享,可以快速对应以及解决问题。所以文中有些地方可能表达有误,欢迎各位大佬指正。
模拟场景
公司和家里两台 PC:
- 公司 PC_A:最初用于搭建 Hexo 个人博客的终端;
- 个人 PC_B:移植 Hexo 个人博客项目的终端。
为了可以随时随地创作更新个人 Blog,两台 PC 中都必须搭建有相同的 Hexo 博客环境,并这必然要求我们的 Hexo 博客本地配置项目要保持同步(即实现版本控制)。
对于 同步 问题:
由于除了静态页面 以外,其它全部文件都在本地生成,所以如果在公司终端上推送了 articleA 文章后回家又写了篇 articleB 文章,在家里推送后我们会发现只有 articleB 文章而 articleA 文章没了(因为家里的 PC 上没有 articleA 文章的 md 文件),故及时同步两台 PC 终端中的 Hexo 博客项目相当重要。
也就是说,对我们的 Hexo 个人博客本地项目实现版本控制是必要的。
— important split line —
这里,我们首先给出新设备环境,解决 Hexo 个人博客多平台同步管理的通用步骤:
- 搭建 Hexo 个人博客环境,包括: Node.js、Git 以及 hexo 的安装,具体安装方式可见前面提到的搭建教程。
- 对 Hexo 个人博客本地配置信息项目实现同步,也就是版本控制。
实施方案分析
介于模拟场景提到的解决方法,搭建 Hexo 个人博客环境本文不在做细致说明,参考前面教程即可。针对同步(备份),这里我们给出三种具体的版本控制(同步、备份)的实施方案分析:
存储设备备份
使用存储设备备份,是指我们使用存储设备对 Hexo 个人博客项目本地文档进行备份。例如,我们可以直接对 PC_A 中最新的本地 Hexo 博客站点目录进行打包存储到硬盘、U盘或者云盘(大多数使用)中,然后将其移植 PC_B 中进行直接使用。
下面我们来分析其优略:
1)优点:
免费且操作简单快捷。
在某些场景下可以很快完成移植,而不需要进行额外的同步设置。例如,当我们的电脑需要重装系统时,我们可以直接将最新的 Hexo 博客项目进行打包,新系统中搭建好 Hexo 个人博客环境后,直接解压几乎就可以使用了。
2)缺点:
- 对于硬盘、U盘等设备,备份后的同步十分麻烦,每次其它终端都需要手动下载备份最新的 Hexo 博客文件夹,进行手动覆盖。
- 目前大多数云盘,可以开启云端自动备份功能,写完 Blog 后可以自动备份(同步)到云端。但是很容易产生一些云盘内部文件,影响 Hexo 解析产生一些不可预期的错误。
因此,使用存储设备备份使用的很少。
第三方代码仓库备份
鉴于之前我们将 Hexo 个人博客产生的静态页面托管到了一些第三方 Git 服务平台,以实现远程访问。同样,类似于代码托管,我们可以将我们的 Hexo 个人博客项目本地配置信息文档托管到远程仓库进行版本控制,以实现多设备的同步管理。这是 目前最合理,并且使用最多 的解决方案。
使用第三方代码仓库进行备份是目前普遍使用的对 Hexo 个人博客进行备份同步的方法。
国内外现在知名的 Git 服务提供商主要有:
Github、Coding 以及 Gitee(码云)等等,使用上没有比较大的差异,但国内站点访问较快。
下面我们来分析其优略:
1)优点:
部署完成后同步非常方便,Hexo 更新完后只需要再更新(push)全站到 Git 远程仓库即可。
2)缺点:
部署过程相对比较麻烦,对 Git 新手不友好,但这仅仅是 Git 使用上的问题,不是难点。
对于使用第三方代码仓库(以 Github 为例)进行备份的方法,目前主流的有两种方法:
- 分支备份法:我们知道,
Hexo
生成的静态博客文件都是上传到GitHub
上的, 且默认放在master
分支上。分支备份法是将本地的 Hexo 相关环境配置文件都推送到对应仓库新创建的分支上(如hexo
分支),以实现备份。 - 将本地整个 Hexo Blog 项目进行备份:创建一个新的仓库用来对本地环境配置文件进行版本管理以及备份。
实施方案细则
下面我们将以前面提到的实施方案给出其具体的操作指南,你可以根据需要选择不同的实施方案:
方案一:Hexo Envs + Cloud Service
–> 步骤一:Hexo envs
PC_A 中我们已经成功搭建和使用 Hexo 博客了,所以不需要重复安装。而关于 PC_B 中 Hexo 个人博客环境的搭建,参考:一文学会 Hexo 轻量级框架的博客搭建【持续更新】 。步骤如下:
- 安装 Node.js
- 安装 Git
- 安装 Hexo
–> 步骤二:yunpan
1)将 PC_A 终端中 Hexo 个人博客项目目录进行打包(打包格式任选,在 PC_B 中可以实现快速解压即可),备份到云盘。
2)然后在 PC_B 中从云盘下载已经上传好的 Hexo 个人博客项目压缩文件,然后进行解压。
3)PC_B 中开启 Hexo 服务,然后打开浏览器,通过访问 localhost:4000
进行 Hexo 博客本地测试,发现已经可以成功访问到我们的 Hexo 本地博客页面。
4)Hexo 个人博客本地测试通过后,由于更换设备,我们需要为Hexo Github·Page(Coding·Page)仓库配置新设备的 SSH Key。此时只需要将新设备(PC_B )的 SSH Key 添加到 Github(Coding)中即可。如果不进行设置,当使用 hexo d
进行推送时无法成功,原因在于 Hexo 无法连接到 Github·Page(Coding·Page)。
关于新设备创建 SSH Key 方法以及为 Github 配置 SSH Key 可参加:Git 使用指南之远程仓库。
除了上述添加方式外,还有一种更简单的方式,我们可以将 PC_A 生成的 .ssh
文件直接放到 PC_B 设备当前用户目录下即可。
自此,设置完成。这种方法缺点很明显,操作太繁琐,对于同步很不友好!!!
方案二:Hexo envs + hexo 备份(Recommended)
这一小节,我们来看如何将本地整个 Hexo Blog 项目进行备份。即创建一个新的仓库用来对本地环境配置文件进行版本管理以及备份。
关于 Git 远程仓库的选择,Github or Coding or Gitee 三选其一即可,这里以 Github 为例,推荐使用 Coding or Gitee。这也就意味着:
Hexo 博客静态页面托管到一个仓库,Hexo 博客配置托管到另一个远程仓库。
–> 步骤一:Hexo envs
PC_A 中我们已经成功搭建和使用 Hexo 博客了,所以不需要重复安装。而关于 PC_B 中 Hexo 个人博客环境的搭建,参考:一文学会 Hexo 轻量级框架的博客搭建【持续更新】 。步骤如下:
- 安装 Node.js
- 安装 Git
- 安装 Hexo
步骤一和方案一种中完全一样,实现 PC_B 上 Hexo 环境的部署。
–> 步骤二:hexo 项目备份
注意,这一部分操作全部在 PC_A(保存了 Hexo Blog 最新进度)上进行,用于将本地整个 Hexo Blog 项目托管到 Github 上的一个全新仓库(以创建 HexoBackups
为例)。
首先,添加设备 SSH Key 到 Github 以提供访问权限(在搭建 Hexo 环境时已经添加过),并且在 Github 中创建 HexoBackups 仓库(操作方法可见:Git 使用指南之远程仓库)。
1)删除 Hexo 站点目录主题路径(Hexo站点目录\themes
)下原有的 .git*
缓存文件夹,并编辑站点目录中的 .gitignore
文件。
有些插件或者主题是从 Github 上 clone 过来安装的,每个文件夹下都会有对应的
.git
文件夹,记得先删掉,否则会和 Blog 仓库冲突。(.git
默认是隐藏文件夹,需要先开启显示隐藏文件夹。.git
文件夹被删除后整个文件对应的 Git 仓库状态也会被清空,避免冲突)编辑
.gitignore
文件的作用是声明不被 Git 记录的非必要文件(我们希望将必要的 Hexo 配置文件进行版本控制,而不是所有文件)。Blog 站点目录下的.gitignore
是 Hexo 初始化时生成的,可以先删除或者直接编辑,对 Hexo 不会有影响。我的 Hexo 默认.gitignore
文件内容如下:1
2
3
4
5
6
7.DS_Store
Thumbs.db
db.json
*.log
node_modules/
public/
.deploy*/.deploy_git
是 Hexo 默认的 .git 配置文件夹,不需要同步;public
内文件是根据source
文件夹内容自动生成,不需要备份,不然版本仓库每次修改内容太多;node_modules
目录中存放了 Hexo 个人博客所需的所有插件,太大,使用时通过npm install
安装即可。.DS_Store
、Thumbs.db
、*.log
、db.json
等均属于非必要文件。
2)初始化本地仓库
Hexo Blog 站点目录下执行以下代码:
1 | <server> 是指远程备份仓库的地址(HexoBackups);origin 是本地分支;remote add 操作会将本地仓库映射到云端 |
“Repository Addr” 即上面创建的用于备份的仓库:HexoBackups 的仓库地址。
3)添加本地文件到本地仓库并同步到远程 Github 上
1 | 添加 Hexo Blog 站点目录下所有文件(.gitignore 声明过的文件不包含在内) |
在执行这步之前一定要注意检查下 .gitignore
文件的内容,看看是否正确的把一些文件夹忽略掉了。如果加错了的话可以用:
1 | git rm -r --cached . |
自此,我们已经成功将本地 Hexo 博客配置文件推送到了 Github 远程仓库 HexoBackups
中实现版本控制。
–> 步骤三:其它设备终端克隆测试
1)添加 SSH Key 到 GitHub
首先,我们需要将设备 PC_B 的 SSH Key 添加到 GitHub 以提供访问权限。
2)将 Hexo Github 仓库内容同步到本地
之前我们已经成功将 PC_A 电脑里的 Hexo 配置信息备份到 Github HexoBackups
仓库了。
现在在 PC_B 电脑准备通过为本地仓库配远程 Hexo Github 版本仓库以实现 Hexo 配置信息同步。
1 | 创建本地博客目录 |
当然我们还可以直接 git clone
将 HexoBackups
仓库中的 Hexo 博客配置文件拉取下来:
1 | git clone "Repository Addr" |
3)安装依赖插件
同步后需要安装相应的 Hexo 插件(这是由于我们之前备份时未备份 node_modules
插件目录),否则无法正常使用 Hexo:
1 | npm install |
4)localhost 测试
PC_B 中打开浏览器,通过访问 localhost:4000
进行 Hexo 博客本地测试,发现已经可以成功访问到我们的 Hexo 本地博客页面。
方案三:Hexo envs + hexo 分支备份
和方案二中备份整个 Hexo 本地配置信息文件到一个新仓库不同的是,分支备份是在原 Hexo 静态页面托管仓库(username.github.io
)重新创建一个分支(以 hexo 分支为例)来备份 Hexo 本地配置信息文件。
最终,username.github.io
仓库的 master
分支和 hexo
分支各自保存着一个版本:
master 分支用于保存 Hexo 博客静态资源,提供博客页面以供人访问;hexo 分支用于备份博客部署文件,供自己维护更新,两者在一个 username.github.io
仓库内也不会有任何冲突。
-> 步骤一:Hexo envs
PC_A 中我们已经成功搭建和使用 Hexo 博客了,所以不需要重复安装。而关于 PC_B 中 Hexo 个人博客环境的搭建,参考:基于 Hexo 轻量级框架的博客搭建 。步骤如下:
- 安装 Node.js
- 安装 Git
- 安装 Hexo
步骤一和方案一种中完全一样,实现 PC_B 上 Hexo 环境的部署。
–> 步骤二:hexo 分支备份
注意,这一部分操作全部在 PC_A(保存了 Hexo Blog 最新进度)上进行。
和 方案二 中备份过程类似,这一部分给出 Hexo 分支备份通用流程,关于操作解读可对应 方案二 中的步骤二。
1 | 消除 Git 仓库冲突 |
–> 步骤三:其它终端克隆测试
1)添加 SSH Key 到 GitHub
首先,我们需要将设备 PC_B 的 SSH Key 添加到 GitHub 以提供访问权限。
2)克隆 Hexo 博客环境
1 | 将 Github 中 hexo 分支 clone 到本地 |
3)安装依赖插件
1 | 安装 Hexo 博客中使用到的插件 |
4)localhost 测试
PC_B 中打开浏览器,通过访问 localhost:4000
进行 Hexo 博客本地测试,发现已经可以成功访问到我们的 Hexo 本地博客页面。
Git + Hexo 管理博文
这一部分我们来看加入版本控制后,如何进行 Hexo Blog 的多平台协同创作 (Git + Hexo)?
–> 步骤一:发布静态页面
假设在 PC_B 电脑上写完了文章,然后进行发布:
1 | hexo d -g |
–> 步骤一:同步 Hexo 最新配置
接下来,我们还需要将新文章的 .md
文件推送到备份仓库。(其实就是提交更新给 Hexo Github 备份仓库):
1 | git add . |
这时候可以用 git status
查看状态,一般会显示刚刚更改过的文件状态。如:
1 | On branch master |
上面的输出状态即说明 db.json
文件做了更改,source/_posts
目录下新增了 test.md
文件。
然后对更改添加说明并推送到远程仓库:
1 | git commit -m '更新信息' |
当显示类似如下提示的时候,即表示备份成功:
1 | To git@git.oschina.net:xxxx/HexoBackups.git |
再回到到 PC_A 电脑上的时候,我们需要拉取最新的 Hexo 配置信息到本地以实现本地仓库和远程仓库一致:
1 | 拉取最新版本 |
即可实现 Hexo 博客同步更新以及协同管理。
自此,基于 Hexo + Github·Page + Coding·Page + Domain + VSCode + MarkDown + TinyPNG + PicGo + Image Host + Git 框架的 Hexo 个人博客创作生态已经建立。
常见问题
Hexo 博客使用过程中的 真·疑难杂症:
hexo init 卡死
Hexo 搭建个人博客时,调用 hexo init 命令一直卡住不动:
1 | hexo init |
这就很困惑了,npm 已经使用了淘宝源,node.js && npm 版本也比较新,就是 hexo init 不成功….
此时查看 Hexo 站点路径,发现目录中已经出现 clone 的文件目录结构:
1 | .git |
网上查找原因,应该是 Hexo 主题未能成功下载(子模块未能成功下载),可以在 .gitmodules 查看相关信息:
1 | submodule "themes/landscape" |
通过查看站点目录下的 themes 目录,发现确实没有相应主题。
–> 解决方法:
为 Git 配置代理:
git config –global http.proxy http://proxyuser:proxypwd@proxy.server.com:port
当然,你也可以等待网络流畅时重新进行 hexo init,说不定下一次执行就成功了。
npm install 很慢很慢
安装 Hexo 博客相关依赖插件时,我们需要使用 npm install
下载进行安装。但是执行指令后一直没反应,这是由于 npm
官方资源被墙,我们可以为其更换一个国内源:
1 | npm config set registry https://registry.npm.taobao.org |
当然,当我们的 Hexo 个人博客使用较多的插件时,npm install
可能看起来很慢(好像卡在某一个安装语句不再执行),此时我们可以通过 Hexo 站点目录下的 node_modules
目录更新时间来判断。
如果 node_modules
目录下各种插件文件更新时间长时间不发生变化,就意外着安装已停止,Ctrl + c
即可。
Git 监测不到空文件夹
Git 无法监测到空文件夹,也就意外着无法将空文件夹 git add
、git commit -m ""
、git push
推送到远程仓库,这会导致 Hexo 博客项目中丢失一些空的功能文件夹。这应该算是 Git 的设计失误。
解决方法:
需要在空文件夹中添加一个占位文件。主流做法是在空文件夹里放置一个 .gitkeep
文件。或者加个 .gitconfig
文件在里面比较实用,也不会觉得突兀,虽然绝大多数时候这个文件不起作用。
Hexo 推送错误
距离上次写博文已经有一段时间了,今天想将最近写好的博文推送到远程仓库,却发现推送不上去了,WTF??!
错误信息提示如下:
ssh: connect to host github.com port 22: Connection timed out
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
然后进行了连接测试,果然发现连接有问题:
1 | $ ssh -T git@github.com |
从报错信息可以看出 GitHub 连接超时,去 ping github.com
也是正常的,浏览器也可以正常访问 Github,于是认为应该不是网络的问题。
第一反应是 SSH 配置出问题了,于是删除掉 .ssh
文件,重新生成并配置 Github SSH 公钥。配置完成之后再次推送,还是上述问题!!!
于是开始 Google 解决问题了。网络上主流思路是“上述问题是由于 22 端口被占用了,修改一下访问端口就好使了!”,这种方法想要同时解决 Github & Gitee 推送是有问题的,不要尝试了!!!
当时采用切换端口的思路,使用
ssh -T -p 443 git@ssh.github.com
进行网络测试,确实是可以连接到的。于是从端口占用角度还去查了环境中 22 端口占用情况,发现也没问题,人方了
走投无路的时候,宿舍同学电脑这时候联不上校园网了,抱怨说学校的网络太辣鸡了~,这时候才想到可能真的是网络问题(有些网络环境下被 q 了),于是尝试使用手机热点进行推送,成功了!!!自此问题解决。
install_url
to use ShareThis. Please set it in _config.yml
.