Githubpage+HEXO : 折腾了2年的建站历程

这篇文章前面讲了很多我建博客的心路历程，想要看简单教程可以拉到最后。

时间线

2016年开始，萌发自己建立一个博客的想法。

2017年初，学习python，据说最简单的编程语言，花了3个月，证明自己是小白。结业作业觉得自己实现不了个人博客的目标，就GitHub上找了个爬虫程序了事。学完之后工作带娃很忙，没有时间和精力，就暂时作罢。

2018年2月春节假期，重新启动这个计划。本来想要花1周的时间搞定，熬夜也可以，但是花了一周之后，并没有很好地运气。就像重新回到初学Python的时候，会被貌似简单的事情卡住，我想我可以给自己再多一点时间。我生日的时候做好，送给自己吧。我的生日是9月。

2018年生日正逢中秋节假期，为了一个小问题熬到3点，blog还是没有建好。但我好像对一些终端命令更熟悉了，效率提升了，建立博客的思路也缕清了，即使没弄好，也是有了信心。

2018年10月份国庆节假期，我又给自己更多时间折腾，终于阶段性成功，hexo博客成功关联到了GitHubpage。

博客和写作

我的计划是，先建立好博客，然后再开始写作计划。但是建立博客的历程，比我想象得漫长。工作和带娃，学习变成很奢侈的事情。

学Python和自己独立建博客两个阶段，都是困难重重，挫折感爆棚。对于我来说，任何困难，都是困难。任何困难，可能都是欠缺基础功，把我困住。

Python导师大妈曰过：

一个简单的日常动作，要被迫点亮多少新技能。“

开智同学ZX说：

搭博客对懂编程的群友只是小事，对没有任何编程基础的群友就emmm…真的可能掉几天坑也没折腾出来，脸上挂满了挫败和怀疑；就算折腾出来可能也花了很多时间，还不知道为啥突然就搞成功。……分享作为小白当时的心路历程... 完全不知道 git 、命令行是何物，第一天在 git+命令行卡了很久，不知道原来本地的命令行和远程仓库是互通的，本地命令行可以连接、操作远程仓库；照葫芦画瓢瞎弄，折腾到半夜两三点，终于搭成功了。。不知道为什么就成功了说的就是我 😢

我的写作计划，要通过我个人博客来实现，但是博客一再被耽搁，我心情变得很糟糕。感觉自己的人生大事都被这件事情卡住了。

我的心态也很不好，我只想侥幸可以顺利通过，命令报错的时候，我不是很有耐心差错，查到自己不知道的概念，也会很无力。学海何洋洋，我不是游泳，是在溺水。

但是后来我冷静下来了，因为我发现，对我而言，对我来说建博客就是为了建博客，和写博客是2件事情。博客不是为了写作，博客是为了博客，是为了了解Cyber世界，这个世界的逻辑和语言，冷静的交流方式。

所以我的困难，对我来说，是补基础功的过程。为了维护我的内心的秩序，保持我的自我效能，我的重点，不在是是否侥幸让博客成功搭建。而是是否，我理解了Cyber世界的语言、规则和秩序。

博客选择困难

为什么建立博客已经不需要再纠结了。除了以上我自己写的写作的理由，知名博主刘未鹏在这篇博文《为什么你应该（从现在开始就）写博客》中已经把你想过的没想过的都提炼出来了。需要纠结的是做什么博客以及怎么弄。说是选择困难，其实是因为很多东西都不懂。

博客方式

知名播主阮一峰提到博客有三阶段：

第一阶段：选择一个免费空间

例子：新浪博客，CSDN博客
比喻：租一个房子，在里面住，但是地不是自己的，也不能自己选择有哪些房间和设备

第二阶段：自己购买域名和空间，搭建独立博客

原因：免费空间限制太多
比喻：自己买地，自己造房子，自己搞硬装，因为太累了，所以软装一般都很丑吧

第三阶段：保留控制权，让别人来管，自己只负责写

原因：独立博客管理太麻烦
比喻：自己买了地，但是用别人的样板间，硬装就直接用别人的方案

第一个阶段经历过，大学的时候用新浪博客写博客，写了好几年。后来发现，我想把博客导出来的时候，很麻烦，得一篇一篇复制出来。那几年的时光记录，花了好长时间去这样整理。必经不是自己的地方，太不方便了。所以现在，我很不喜欢在各大平台上写作，顾忌是，如果有一天我想整理这些内容，会很麻烦。

第二个阶段没有经历过，很简单，没有这个能力。

所以现在在尝试的就是第三个阶段。

博客类型：静态网页 VS 动态网页

静态网页：每个网页都是独立文件，没有数据库支持
动态网页：①以数据库技术作为基础，可实现更多功能；②根据用户的要求相应地响应和改变

这个结论很简单：选择静态网页博客。原因是：

博客不需要太多交互，我只想安静得做图文，甚至是纯文博客。
静态更稳定，也更轻。
更重要的是，动态网页更复杂，我应该搞不来，从最简单的开始。

博客框架：Jekyll vs hexo vs Pelican

其实博客阶段选择，以及静态动态选择，都是默认选项。真正困难的是选择什么服务，我看了很多人家的经验贴。因为我成功率一向很低，不像大牛，可以建完这个，觉得不顺心再换一个，所以折腾成本相对较高。在选择的时候，也尽量慎重，害怕自己因为一时无知给自己后面留无法填补的坑。

我看了主流的一些选项，发现主要PK是Jelyll和Hexo。这两个博客服务的攻略贴很多。大妈还提出Python选项的pelican。

jelyll

jelyll比较硬核，阳老师推荐这个。并且是GitHub默认支持的选项。

之所以用Jekyll，是希望专注于写作而非版式、图片等。——阳志平

缺点是：

扩展性不太好

用Jekyll管理博客，单纯写文章很便捷，但是它的扩展性，灵活性和对配置的支持都相对局限，这是我转向Hexo最重要的原因。弃Jekyll投Hexo

对非程序员不太友好

jekyll用的liquid语法确实不是对程序员友好的，用起来很痛苦。不过jekyll功能比hexo强大很多，有时间折腾的可以选它。 wordpress-jekyll-octopress-hexo四博客引擎比较

提交到 GitHub 上生成的静态页速度很慢把 Blog 从 Jekyll 迁移到 Hexo

Hexo

选择Hexo的比较多，开智的同学大多数选择了Hexo，比如浚宇 & 广鹤。

Pelican

大妈推荐了 Pelican，并对hexo做了点评。

Hexo 是 nodejs 的作品 , 本身除了丰富的动态效果, 对于静态 blog 系统本身的功能并没有多少创新,在理解了静态网络发布的流程后,使用 python 开发的同类系统, 还能自主加以改进,可能是更加嗯哼的选择...俺推荐 Pelican ;-)

查了资料，了解了一下Pelican的优点。

今天我终于用用Python开发的Pelican静态博客系统和Github Pages替代了原来的WordPress博客，站点变得清爽和轻量级多了，静态站点了访问速度非常快，重要的是: 彻底告别臃肿的WordPress管理后台，文章可以直接用markdown格式在Sublime Txt里写，提交到Github用版本库管理起来，正式发布则只需要敲一行fab命令——Felinx Lee:博客复活

结论:

选Hexo：有全职工作冲刺KPI的老母亲，经不起折腾
不排除通过哪个库成功，所以最后选哪个的可能性

实际操作的时候，这3个都尝试过，但是初次尝试都不太成功。主要是很多概念不太清楚。包括Git，GitHubpage如何关联之类的。后来主要选择了Hexo作为主攻对象。

时空迷路症状

出现症状：安装好jekyll后，推到Gitpage上失败了。

现在查看log，猜测当时失败的原因是：在安装jekyll之前：①已经在GitHub上建好仓库，好像还把这个仓库clone到了本地; ②安装过Pelican，关联了GitHub的仓库

Where do you want to create your new web site? [.] https://yiiina.github.io
> Done. Your new project is available at /Users/Yina/Desktop/blog/https:/yiiina.github.io

安装jekyll自动建立了一个文件夹/Users/Yina/blog，这个文件夹和GitHub仓库clone到本地的文件夹/Users/Yina/Desktop/blog/https:/yiiina.github.io不是同一个文件，所以冲突了。

当时不知道为什么，当时对各种空间概念很模糊，所以即使出错也不知道错在哪里，所以复习了一下Git的教程。并梳理出博客空间地图。

一定要很有空间概念，知道文件数据是如何在不同位置传递的

博客时空地图.png

起点：你想成为一个创作者，于是在本地开始进行创作，本地会有一个文件夹
终点: 你想让大家看到你的作品，所以要将本地作品发布到网页端

本地文件夹 →【创建本地服务 → 远程托管】（版本管理） → 发布

1. 本地：从起点「文件夹」开始

这个很好理解，就是日常使用的放文件的文件夹。

然后你需要进行高效的版本管理，所以使用了Git，Git是很厉害的版本管理理念，超级灵活的时空穿梭机。

2. 大脑时空穿梭：本地工作区 → 暂缓区 → 仓库（版本库）

空间这块，有几个重要的概念：

本地工作区
暂缓区
仓库（或者叫做版本库）

版本库，就是你可以准备提供的服务了，这里面有了不同时间点，你曾经提交过的版本，可以自由穿梭。

在这之前的暂缓区，是你新做好了一些工作，但是还不确定，所以先待定，或者改动比较小，无所谓作为一个版本。

在暂缓区之前的本地工作区，就是你的草稿纸，资料室，工作台了。

工作区就是可以看到的本地文件夹的文件，暂缓区和版本库，其实是肉眼不可见的，没有GUI(图形交互界面)，所以会很难理解。

3. 本地访问：4000

4. 远程访问：服务器、空间和域名

给用户提供服务，需要通过服务器。不然很多人访问你的个人PC,不是要崩溃？你如果不联网，别人就无法访问了。

开发完成后，只能在本地工作，别人电脑访问不到，希望让别人也看到，就需要部署。

部署：开发的产品在某一环境中运营起来。

所以你需要把自己的博客，提交给网络主机，他们装有服务器，可以让更多人，随时随地访问你的博客内容。

域名：让别人找到你的名字。
空间：你购买的服务器提供的服务。

用户可以通过域名，调取你在服务器中的数据，访问你的博客内容。

服务器是，管理资源并为用户提供服务的计算机软件
服务器包括：文件服务器、数据库服务器、应用程序服务器
运营以上软件的计算机，称为网络主机（Host）
最大的特点：运算能力非常强大，短时间完成所有运算工作
作为硬件：计算能力高，给多个用户使用的计算机。
PC 给一个用户服务，服务器可以给多个用户使用，主机通过终端给用户使用，服务器通过网络给客户端用户使用。
服务器的构成与一般的PC比较相似，但是服务器在稳定性、安全性、性能等方面都要求更高，因为CPU、芯片组、内存、磁盘系统、网络等硬件和普通PC有所不同。

域名解析就是域名到IP地址的转换过程。域名的解析工作由DNS服务器完成。

DNS （Domain Name System）根据域名查出IP地址，你可以把它想象成一本巨大的电话本。

5. Git & GitHub & Githubpage

git
Git进行版本控制，软件源代码托管服务
分享学习，协同合作

github
你可以在GitHub上保管项目，也可以分享项目，学习别人的项目
github提供的用于为用户，用户博客，项目甚至整本书提供的静态网页托管服务
GitHub还提供一个网页托管服务，相当于提供免费的服务器，域名和空间，让你的博客内容让其他人看到

Githubpage:

a static site hosting service
designed to host your personal,organization,or project pages
directly from github repository

6. 用户访问：Web

现在用户可以访问你博客上的内容啦。

习惯养成：像看说明书一样看文档

遇到问题，去看文档，一开始我也是拒绝的。总是抱着侥幸的心理，说不定哪个博客的神奇操作就解决了问题，路就走通了呢。然而运气总会用完，文档是你可靠的朋友，不会给你虚假的希望。看文档需要：耐心、看大段英文的勇气，看多了看英文也就不怵了。

在我建博客过程中，遇到了3个大坎，都通过官方文档，解决了问题。

配置有问题，导致HEXO安装遇到问题，硬头皮磕源文档，成功解决
后来不太懂SSH是什么，也好像掉进了一个坑里，后来通过官方文档解决
hexo和GitHub关联遇到问题，看了很多博客，后来也是在官方文档找到了解决方案

安装HEXO, 生成本地的服务

最一开始，按照一般的教程配置HEXO环境有问题，导致无法成功安装HEXO。安装就遇到问题，这是新手小白很痛苦的体验。后来完全跟着文档走，解决了问题。

安装node.js，包含环境变量和npm

npm安装HEXO,没有成功,报错信息关键词：errno -13、access

$ npm install -g hexo-cli

看HEXO文档提示,安装Xcode和命令行工具

Mac 用户:您在编译时可能会遇到问题，请先到 App Store 安装 Xcode，Xcode 完成后，启动并进入 Preferences -> Download -> Command Line Tools -> Install 安装命令行工具。

重新安装HEXO，还是没有成功

$ npm install -g hexo-cli

看错信息关键词，没有搞明白问题在哪里，也没有看文档。在别人博客看到在安装命令之前加了sudo，就成功了，就也想有这种运气，好像装好了。

$ sudo npm install -g hexo-cli

但初始化的时候，结果还是没有成功，卡住了，有npm WARN，回避不了NMP的问题

$ hexo init myblog

Google搜到问题讨论ISSUE,顺藤摸瓜，找到NMP的文档How to Prevent Permissions Errors
官方提供2种方法

用版本管理器重置NPM(推荐)——nvm
手动改NPM的默认目录

方法2是人家博客里SUDO做的事情，但是我不太懂目录，之前这么操作也没有成功。
方法1是官方推荐，就老实照做了，并且像看说明书一样看文档，一步一步去排查问题和操作

安装nvm

$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

新开一个终端，验证nvm是否安装成功

$ command -v nvm

nvm安装npm

$ nvm install node

安装HEXO

$ npm install -g hexo-cli

用HEXO新建一个网站 → 生成静态文件 → 启动服务器,成功了，可以在本地服务器看到页面了，打开有点小小激动呢，这是一个第一个里程碑哦。

$ hexo init blog
$ hexo g
...
INFO  28 files generated in 362 ms
$ hexo s
INFO  Start processing
INFO  Hexo is running at http://localhost:4000 . Press Ctrl+C to stop.

image.png

HEXO和GitHub关联

建站之后，一直卡在HEXO和Githubpage的关联上。

时空地图

开始之前，我先想搞清楚一个问题。

A 先从GitHubpage clone到本地，在本地重新建一个HEXO？
B 还是先本地建一个HEXO,再关联到Githubpage的仓库？

这个本质上是我对Git和GitHub的时空感还不太好。

实践过程中，又发现并解决了2个关键的问题：

SSH
HEXO部署到GIT

实践A：的过程中遇到SSH的问题

通过实践再理解一下Git和Github时空地图过程中，在本地建了一个blog文件夹，然后想把远程的clone下来, 再进行HEXO建站。

$ Git init
$ Git clone Git@git@github.com:yiiina/yiiina.github.io.git

但是失败了，原因是 Permission denied (publickey)

谷歌搜索到GitHub的官方帮助，列出很多可能的原因，其中有一个是是否有在用的key。

之前已经在SSH上昏过一次，我以为解决了，但是还是出现了问题。

第一个命令之前看到过，但是有反馈，我以为我有，就没有再去弄。

$ eval "$(ssh-agent -s)"
Agent pid 26950

但是看到下面这句话，试了一下确实没有。

The ssh-add command should print out a long string of numbers and letters.
If it does not print anything, you will need to generate a new SSH key and associate it with GitHub.

$ ssh-add -l
The agent has no identities.
$ ssh-add

所以要新建KEY

$ ssh-keygen -t rsa -b 4096 -C "n****@gmail.com"

再试一下,现在确实有一串数字和文字出来了。

$ eval "$(ssh-agent -s)"
Agent pid 26996
$ ssh-add -l
The agent has no identities.
$ ssh-add
Identity added: /Users/Yina/.ssh/id_rsa (/Users/Yina/.ssh/id_rsa)
$ ssh-add -l
4096 ....:Nf7t......JA /Users/Yina/.ssh/id_rsa (RSA)

SSH建好了，把这个秘钥打开，输入到github的设置里。这个步骤有参考《GitHub入门与实践》P29
很直观。

yina:blog Yina$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAA.......w== niceyina@gmail.com

这次再试一下，就OK了。

yina:blog Yina$ git clone git@github.com:yiiina/yiiina.github.io.git

从github克隆到本地的仓库，HEXO无法初始化，必须要在空文件夹, 路径A证明失败

not empty, please run hexo init on an empty folder and then copy your files into it

实践B：漏掉HEXO部署到GIT的步骤

现在就是路径B了。其实路径B的方法，就是本地生成HEXO的时候，修改注册表信息。

之前看开智极简教程，漏了一个步骤：把HEXO部署到GIT。

整个过程一直无知觉的状态。后来搜一个不太直接相关的问题，在一个博客里发现了这个步骤，再去文档查到了这个。

$ npm install hexo-deployer-git --save

说这个包已经不再维护了，按照提示，输入修复命令,OK了

$ npm audit fix

此时再进行部署

$ hexo d

这时候LOCAL host和网页端的就一样了。