如何正确地更新主题

[xaoxuu]

link: https://volantis.js.org/how-to-update/

如果您以内容创作为主，推荐使用稳定版本：

npm i hexo-theme-volantis

更新时，把 package.json 中的版本号改为 * 再执行 npm i 就可以了。

如果您需要对主题的源文件进行修改，推荐 fork

引用并修改自己 fork 的那份，当主题有更新时，合并到自己的分支。

如果您不 fork 而直接修改主题源码，是没办法获得更新的！

[inkss]

如何正确地更新主题（Fork 篇）

  本文以 GitKraken 软件的使用展开，相关链接：GitKraken: Free Git GUI Client - Windows, Mac, Linux

  如果您按照主题文章中的 设置子模块 已经克隆了一份主题并添加到自己的博客仓库中，那么本篇文章将极大的帮助到您，如果您还没有如此操作，不妨尝试一番。这里是本文的仓库环境：博客仓库 Hexo-Blog 、主题仓库 volantis 。

一、GitKraken 的简单操作

  在 GitKraken 的软件界面中，位于正中间面积最大的区域是仓库的历史提交信息，右边为选中提交记录的详情，左边则放有一些仓库相关的信息，将目光集中到左边的 SUBMODULES 选项栏，如果您已经正常的将 Fork 的主题仓库添加到博客仓库中，您便可以在这里看到。展开 SUBMODULES 选项卡，右键并选择 Open this submodlue 打开子模块：

博客仓库

打开子模块

  如此进入的仓库为您的主题仓库，可以在当前页面中查看到所有提交的历史记录等等。为了避免一些拗口的称呼所带来的不良影响，这里设定如下：将 Fork 的仓库称为 主题仓库 ，将 hexo-theme-volantis 仓库称为 volantis 仓库。

主题仓库

  在图中，当前 Fork 的主题仓库所处的分支为 master-theme ，图中右侧展示的是个人主题仓库的最后一次提交信息。中间区域，较上部分在写有 master 标记的为 volantis 仓库的分支（您可以通过右侧的 Logo 图片进行区别）。显而易见的，当前主题仓库已经落后 Volantis 仓库，下面我们便需要合并代码到自己的主题仓库中。如果您打开后的界面并没有看到 Volantis 的仓库信息，意味着当前没有添加 Volantis 仓库为远端，您可以按照如下操作添加：

添加 Volantis 远端仓库信息

  在左侧面板的 REMOTE 选项卡处，点击加号，进入如下图所示界面，选中 volantis-x/hexo-theme-volantis 后添加即可。

二、GitKraken 的合并操作

1. Merge

  在 volantis 仓库的 master 分支处右键，选择 Merge volantis/master into xxxx，进行合并操作。至于为什么不选择变基（Rebase），个人认为保留仓库的提交历史比修改历史更好。通常，合并操作会自动完成，但是如若冲突时，会收到如此提醒：Merge Failed ,There are merge conflicts that need tobe resolved. 如它所说存在需要解决的冲突，此时右侧选项卡会展示 Merge conflicted detected 窗口，已解决的和冲突文件会显示在其中。

  点击待解决冲突的窗口，在这个页面中，上半部分为本地和远端的代码，下半部分为合并后的内容。您可以根据实际情况，如回忆修改历史，选择是选中左边本地，还是右边远端，抑或是两边都选择，如果对选择后的结果不满意，您还可以手动修改 Output 窗口中的内容，当一切结束后，点击 Save 结束操作。（原则上您必须选择其中的一方，而不是直接修改 Output 的内容）

  有时，可能遇到远端删除了某个文件，收到如下提示：GitKraken was unable to determine whether to keep source/css/_plugins/gitalkstyl, would you like to keep it? GitKraken 不会主动删除您的文件，不过一般情形下无需保留，Delete The File 即可。

  最后，在解决完所有冲突文件后，回到仓库列表界面，点击 Commit and Merge 完成提交。

A. 合并操作

B. 合并冲突检测

C. 选择合适的内容

D. 提交内容

2. Rebase

  简言之，Rebase 将你的所有修改（提交）重新放到了公共分支的最后面，当然后果是可能会经常面临是否强制提交，而且不太适合与 Merge 操作共同使用。以下内容摘抄自：Rebase - 廖雪峰的官方网站

多人在同一个分支上协作时，很容易出现冲突。后 Push 的童鞋不得不先 Pull ，在本地合并，然后才能 Push 成功。

总之看上去很乱，有强迫症的童鞋会问：为什么 Git 的提交历史不能是一条干净的直线？其实是可以做到的！Git 有一种称为 Rebase 的操作，有人把它翻译成“变基”。

Rebase 操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

• Rebase 操作可以把本地未push的分叉提交历史整理成直线；

• Rebase 的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

三、冲突的产生与避免

  冲突一般产生于同一处被不同人修改时，Git 无法自动处理，抛出错误让用户解决。由于主题目前仍处于青少年阶段，更新迭代速度比较快，冲突现象可能会比较明显，下面提供一些思路减少这类情况。

  1.首先是配置文件，根据 Hexo 的规则，所有对配置的修改都可以独立出来，无需直接修改主题仓库下的 config.yml ，这里可以参阅：使用代替主题配置文件。配置类文件是最不该产生冲突的地方。

  2.样式文件，根据 css 的覆盖规则，使用样式覆盖比直接修改样式来的欢快，例如主题中的光标便是采用的样式覆盖的思路。

四、代码历史维护

  您可以对单个文件进行历史查看操作，以此来对比您所做出的个人修改，最大程度上的避免代码丢失。正所谓熟能生巧，多加操作后主题更新将不再是一件麻烦的事情，末尾愿您一路走来，最终回归创建博客的初心，完结撒花 ★,°:.☆(￣▽￣)/$:.°★ 。

历史记录