每次更改完 NexT 文档 都要手动部署到 GitHub Pages，重复的次数多了就显得很麻烦，出错的几率也会变大。文档源码放置在 master 分支，最终部署文件在 gh-pages 分支。当在 master 分支更改某些内容之后，通过运行 gulp dist 来生成最终部署的 HTML 文件到 dist 目录，随后再进入 dist 目录初始化 git 仓库、添加文件、提交文件，最后将提交强制推送到远程 gh-pages 分支（因当心我会误将最终部署的 HTML 文件提交到 master 分支导致源码丢失，我在 GitHub 上把 master 分支给锁定了）。除此之外还有另外一个问题：如果 master 分支有 Pull Requests，我需要先将更新取回本地，然后编译更新再提交回远程 gh-pages 分支。

年轻的想法

于是，我就想这说将这个过程自动化。首先考虑了使用 GitHub Webhooks，这是 Github 提供的一种机制，使应用能与 Github 通讯。这种机制实际上就是 Pub/Sub，当 Github 监测到资源（如仓库）有变化就往预先设定的 URL 发送一个 POST 请求（Pub），告知变化情况，而后接收变化的服务器（Sub）即可做一些额外的事情。

这个思路需要有一个服务器并启动一个服务来接收 Github 的请求。这里又有种不同的策略，这两种策略都是基于源码放置在 Github 的前提。第一个是源码将最终文档直接部署在这台服务器上（如使用 Nginx），当接收到 Github 通知直接编译更新到服务器指定的文件夹下即可。另一种策略是当服务器接收到通知后编译更新，而后将编译后的版本提交到 Github 仓库的 gh-pages 分支，让 Github 做 Host。

尽管简单易用一直是 NexT 主题的首要目标，但现实与想法总是有那么一个缝隙，难怪有人说诗要源于生活后低于生活，着实有着深刻的哲学道理。那么无论这背后是什么样的原因导致，总结起来就是 NexT 不好用。在初期使用者比较少的情况，还可以有耐心的一个个解答；后来发现一直在回答类似的问题，加上要做和想做的事情太多而无暇顾及，于是就想写一份文档缓和一下这个问题。

前季剧情回顾

起先，我使用 Hexo 搭建了第一版的 NexT 使用文档站点。UI 框架选择的是 Semantic UI，并且新建了一个主题称为 Luminosa。然而我发现要在 Markdown 里使用 Semantic UI 的组件有点麻烦，以及 Hexo 在解析 Markdown 时会自动加上很多空行的问题。不得已之下，只能创建了几个 Tag Plugins 封装了一下使用到的 Semantic UI 的组件。

十一月真是一个忙碌的季节，电商平台携商家精心布局撒网等鱼入网，买家手握巨款蠢蠢欲动，物流赶忙提升内容分发系统的高效性与健壮性，一副生机勃勃的画面。作为不怎么热衷购物的我在这番阵势下也激动的跃跃欲试，为了做好热身运动，我提前升级了下电脑设备。那买买买的节奏可谓十分轻快明朗，让人欲罢不能。钱要花在刀刃上，这是我获得的人生的第二条真谛，还挺早获得的，就是执行力不够。我把这个错误归结为冲动的欲望在作祟，但很明显是自我欺骗，显然应该怪商家太会营销打广告。

常话说的好，高富玩表，土豪玩车，屌丝玩电脑。作为一名屌丝中的战斗机，那电脑必须玩得溜。人生真谛第三条，既然决定做一件事情，就把这叫事情做好，无关贫富贵贱，此乃工匠本色。看着那些陪伴多年，依然坚守岗位默默奋斗的电子设备，我想是时候了，是时候来个咸鱼翻身，再扑腾一阵子。

NexT 主题 快满一周岁了，值此之际，碎碎念一下（没有干货）。正如我在 V2EX 分享 时的介绍一样，NexT 的前身叫做 Notes。在做 Notes 主题的时候，基于当时的需求出发点，从好听上来讲是简洁，不好听就是简陋（真直接，脸红）。

Notes 开发于我刚接触 Hexo 时。当时我拥有一个基于 WordPress 的独立博客，这个博客主要用来写比较完整的技术类文章。在拖延症与技术挫的主观加客观因素综合作用下，这个独立博客也是产出寥寥。然而在丑小鸭能变美丽天鹅的唯美段子的安利下，我也是每天勤勤恳恳钻研技术（折腾不休）。每日阅读各路教程，搜索各种解决方案，追根溯源探索背后的原理，企图从根本上回答 “我是谁？我从哪里来？我要到哪里去？” 这类哲学问题。