前一篇我们介绍了如何使用 Hexo 框架及 Next 主题搭建博客。这次来聊聊如何安全的更新博客与主题的版本。

早期写博客时笔者就有考虑过使用 git 来做版本控制，那时 github 私人仓库还没有免费开放，国内虽然有 coding 和码云这些平台有开放少量的私人仓库，但由于懒得折腾就选了最方便同步的 OneDrive(因为它只需将文件夹移入就可以实现跨设备共享)。

后来笔者因为工作的原因，需要在多设备中频繁切换，这种简单同步方式就会暴露出一些问题。比如说，在设备 A 想对博客做一些自定义的修改，其中可能会动到依赖，但此时设备 B 的文件正在同步，那这样可能会导致文件不一致的问题。可能会将旧的文件重新同步过来，这可能会导致程序报错，还不易于排查。

冲突文件合并失败会额外添加如 index-anran758's MacBook Pro.js 之类的同名文件，并且发生冲突时是隐式的，你甚至不知道发生了冲突，这种体验使用不太友好。

因此 OneDrive 的同步方式适用于改动不会太大的文件。

如果你对 git 版本控制比较熟悉的话，那可以通过 git 对 blog 进行版本控制。

使用源码托管平台的话就如上文所说主要有这么几种选择:

国内的 gitee(码云)、coding 是一个不错的选择，代码的上传于下载速度也比较可观。国外可以使用 github，github 的私人仓库是今年才开放无限制免费创建仓库数量的，缺点由于众所周知的问题，有时可能拉代码速度较慢。

笔者使用的是 github 作为源码托管，下文将要介绍的方法对于 git 仓库是通用，因此根据自身的喜好选择对应的平台。

博客托管

托管 blog 源码的步骤如下:

1. 找到对应的平台，创建私人仓库(注意是 Private，不要将自己的私人配置也开源咯)。

2. 仓库创建完毕后，得到仓库的地址。打开命令行，进入 /blog 目录下并输入命令:

   1 2 3 4 5 6

   git init git remote add origin your_repo_path

3. 由于 /theme/next 本身也是一个仓库，git 无法提交嵌套仓库的文件夹，因此需要在 .gitignore 添加配置，忽略该文件夹

   1 2	themes/next/

4. 提交代码

   1 2 3 4 5 6

   git add . git commit -m "new: blog 数据开始进行版本控制" git push -u origin master

5. 这样我们就完成了博客的源码托管。

主题托管

Next theme 官网介绍的安装方式如下:

1
2
3
4
5

cd blog


git clone https://github.com/theme-next/hexo-theme-next themes/next

在 Next theme 7.0+ 版本中，主题嵌入了检查版本更新的代码，每当运行本地服务器时，都会进行检查版本号的更新。当有新的版本发布时会在命令行输出警告:

1
2
3

WARN  Your theme NexT is outdated. Current version: v7.4.2, latest version: v7.5.0
WARN  Visit https://github.com/theme-next/hexo-theme-next/releases for more information.

这时你想体验 Next 的新特性的话可能会有点麻烦，因为原先我们在旧版本上修改了配置，或添加了一些自定义的布局。这将会造成代码冲突。

因此我们需要独立开两条分支:

• master 分支是官方发布的正式版本，我们不去修改 master 分支的中的任何文件。
• 另一条是我们自己创建的新分支，笔者命名为 customize, 言下之意为该分支含有我们自定义的修改，包括私人配置等。

除此之外，由于主题配置文件(theme/next/_config.yml)中含有某些应用的 appid 或者 secret，这些配置不应该被其他人随意看到以防冒名滥用。因此我们应该将该项目额外添加一个 remote 来保存我们的私人配置。 具体操作如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

git checkout -B customize




git add .
git commit -m "chg: 修改为自定义配置"


git remote add userRepo git@github.com:anran758/hexo-xxx-next.git


git push -u userRepo customize

如此就完成了代码的追踪，以后使用 next 主题就不是从 hexo-theme-next 中获取了，而是我们自己的私人仓库 hexo-xxx-next 中获取，安装方式是一样的。

版本升级

Next

前文说过我们将源码托管的需求之一就是为了解决代码合并的问题，为了体验新版本的特性，我们需要将新版本的代码合并进我们的分支：

1
2
3
4
5
6
7
8
9
10
11
12
13

git fetch origin
git pull --no-commit origin master


git checkout customize


git status


git merge master

我们最起码修改过 _config.yml，因此会发生冲突也不奇怪，有冲突咱们就解决冲突。

如果你使用 vscode 进行编码，侧边栏有一个源代码管理，打开它可以看到冲突的文件。

打开冲突的文件，判断冲突项确定要保留(删除)的代码，解决冲突后，提交到缓存区(git add .(file))。缓冲区有本次升级所涉及的代码，可以大致预览一下本次的更新都做了什么事

1
2
3
4
5
6
7
8
9
10
11
12
13

git commit -m "Merge release v(version) into customize branch"


git push

升级完后运行本地服务器最后会输出一条：

1

INFO  Congratulations! Your are using the latest version of theme NexT.

Hexo

若最新版本的 Hexo 引入了你想要的新功能，你想更新 Hexo 版本的话，首先确定版本号变动的是哪一位。

package.json 的版本号格式是数字由点分隔，如 主版本号.功能版本号.补丁版本号。若更新是主(大)版本号的话，则需要先修改 dependencies 依赖中 hexo 的主版本号，再输入 npm update。

以下是 hexo@v3 更新为 hexo@v4 的示例:

1
2
3
4
5
6
7

{
   // ...
   "dependencies": {
+    "hexo": "^4.0.0",
-    "hexo": "^3.9.0",
  }
}

命令行输入:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

$ npx hexo -v
hexo: 3.9.0
hexo-cli: 2.0.0
os: Darwin 17.7.0 darwin x64
node: 12.13.1
v8: 7.7.299.13-node.16
uv: 1.33.1
zlib: 1.2.11
brotli: 1.0.7
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
napi: 5
llhttp: 1.1.4
http_parser: 2.8.0
openssl: 1.1.1d
cldr: 35.1
icu: 64.2
tz: 2019c
unicode: 12.1

$ npm update
+ hexo@4.2.0
added 71 packages from 90 contributors, updated 14 packages and moved 5 packages in 12.513s

$ npx hexo -v
hexo: 4.2.0
hexo-cli: 3.1.0
os: Darwin 17.7.0 darwin x64
node: 12.13.1
v8: 7.7.299.13-node.16
uv: 1.33.1
zlib: 1.2.11
brotli: 1.0.7
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
napi: 5
llhttp: 1.1.4
http_parser: 2.8.0
openssl: 1.1.1d
cldr: 35.1
icu: 64.2
tz: 2019c
unicode: 12.1

若只是后面两位版本号有变更的话，仅需输入 npm update 即可。

总结

单单从升级版本来合并代码的角度来看，实际上本地 commit 也可以做这种事，将 commit 储存在本地(.git)中不提交远端也是没有问题的，OneDrive也可以完成同步。

但从安全和可调试的角度来看，OneDrive的同步方式存在一定风险(懒的代价)。使用 git 版本控制可以清晰看到每一次提交的修改，不会多出奇奇怪怪的东西。必要的时候还可以进行回滚，相对来说更安全。但这种方案需要使用者了解一定的 git 知识。

从操作步骤来看，使用的 git 同步方案会产生多个仓库，这些仓库一般是拥有权限的人才能查看(修改)源码。比如完成了本文中两个仓库源码同步后，在另一台设备初次同步的步骤是：

1. 通过 git clone 下载 blog 本体。
2. 通过 git clone 下载私人仓库 next theme 到 /theme 目录下。
3. 进入两个仓库内安装对应的依赖

以上可以在 blog 项目下的 package.json 设置 scripts，通过一条命令来完成这些事。

由此我们可以看到，相比 OneDrive 的懒人方案，git 方案的操作步骤会更繁琐。更新方式也从自动更新变成手动更新。

两者种方案各有利弊，具体采用什么方案就看朋友们的习惯啦~

本文涉及到的 git 命令都是可以在 git 速查方案 查找相应的解释。