重建Hexo的教训

再次看到的这个博客,默默的搬了一次家。

昨天睡前想检查一下博客的访问量,在“百度站长”的“抓取测试”发现了403报错。难怪我的博客从来没有来此百度搜索的流量。难道百度被Github屏蔽了?果然是这样:如何解决百度爬虫无法爬取搭建在Github上的个人博客的问题?。知乎上已经开始讨论如何解决这个问题。我的又一次博客折腾之旅从这里开始……

大坑

查看了资料之后,自己有了思路,在Coding Net上再注册一个账号,利用Coding-Pages和Github-Pages同时部署两套静态网页,DNSPOD解析不同的来源到不同的静态网站。

文件消失

想好了就开干吧,想新建一个空白分支,把分支同步到codingnet保证分支没有内容,方便后后面的hexo deploy。噩梦从这里开始了,我先搜索了一下如何新建一个空白分支

1
2
3
git checkout --orphan coding-pages
git rm -rf .
git push -u origin coding-pages

看到rm命令就不敢继续做下去了,返回master,结果返回之后惊呆了:

  • 之前修改的文件没有保存到工作区,貌似找不到了
  • next主题的文件是submoduel,在这个仓库里并不保留,消失了。

这意味着自己之前修改过的next文件都没有了,需要重新搞一遍。这时候已经是早上一点了,一会还得上班,郁闷中睡去。睡前终于想明白为什么next文件会消失了,因为submoduel的文件没有在自己的仓库存储,而远端仓库连接的是next主题的官方文档,自己也一直没当回事儿,悔…

部署失败

第二天自己再工作中抽出了一些时间试一下恢复博客。首先用我的hexo.junyu.pro做了测试,同时部署github和codingnet,成功。然后fork了next的主题文件,不过考虑到自己的配置文件中有大量的私人ID,删除了仓库。新建了私人仓库,重新clone了next主题仓库,并且把大量的个人配置和页面修改在仓库进行了记录。之后,回到自己的最重要的博客配置。

尝试了一会,发现自己在从零开始新建Hexo博客提到的“疑难杂症”再次出现。不过这一次比上一次有了更多的探索和进步,虽然找到了变通的办法,但是还是没有彻底解决问题,具体情况在未解之谜有详细的说明。

解决了这个问题,后面的过程相对简单,部署完成之后测试,发现如果我在“科学上网”的状态下,访问自己的网站是报错403。因为github正常访问而codingnet无法访问,初步判断是域名解析过程出现问题,走的依然是国内的通道。这个问题也在未解之谜有详细的说明,希望有小伙伴可以帮忙解决。之后测试了一下,发现百度可以正常抓取,基本工作才算结束。

文件残留

由于我是利用git的多个分支方式管理自己的在创作中的文章。新建了git仓库,原来的仓库不再有效,好几篇文章面临要尽快处理,所以产生了文件残留,而且过去的历史也都不复存在。

教训

总的来说,这一次的“折腾”花了点儿时间,有一些文件的损失。但是收获也是有的,每一次程序的探索过程伴随着新的认知理解。毕竟博客发布的文章没有损失,零碎的卡片丢失并无大碍。

技术学习和实验的方法

  1. 不要随便执行不清楚的代码
    • 曾经看到一篇知乎求助帖,有人在下面回复如下 rm -rf。这是一个极其不负责任的答案和有可能产生非常严重后果的玩笑,不了解代码的可以参考这里的故事:不小心敲了rm -rf后反应是怎样的?。后面就有人回复了一句程序员的金句:不要随便执行不清楚的代码。
    • 这一次的问题最开端是一行命令 git checkout --orphan coding-pages。我并不了解,直接在自己的博客正式环境执行,带来了不小的代价。希望自己引以为戒。
  2. 新技术必须设置好环境测试后再考虑合并代码
    • 如果昨晚在做测试的时候用的是我的测试环境,就不会出现这样的事故。所以在尝试新的技术、新的代码、新的环境之前,都要先考虑到最坏的情况。
    • 其实在自己的工作中这一点是非常重要的,生产环境出现问题的影响非常严重。可是回到自己的博客上竟然忽略了这一点,“跨情景“的学习没有做到位。工作中会有专门的测试环境用来做新的尝试,确认无问题之后,才会部署到生产环境进行测试。既然博客是我的重要的平台,也应该遵循这个规则。
  3. 要做好备份工作
    • 在实际工作中,企业的生产环境会根据重要程度进行灾备、热备等。我的博客虽然不需要考虑到那么麻烦,但是备份的意识也是要有的,应该考虑到最严重的情况,做到有备无患。
    • 我的博客备份可以考虑的几种方式:在codingnet和github的同时部署、在github根据更新的情况发布不同的版本、fork独立的仓库备份、本地存储备份等。
  4. 学习要学的彻底
    • 这一次新的尝试,掉入的坑都是以前没有彻底搞明白的问题,本来以为自己不会再遇到这些问题,博客终于“尘埃落定“,没想到这么快就遇到了风险,不能抱有侥幸心理,要学习就得彻底。这一次的问题参考下面的说明

关于博客的输出

在这段时间除了已经发布的博客内容之外,自己还积累了大量的素材,本想着慢慢写,不着急。可是一推脱,事情就发生了。早点把自己的知识梳理出来,在恢复的过程里会帮助自己更快的处理问题。后续的博客输出也会尽快,毕竟博客技术千字文还是有一些区别。千字文要快写慢改直到自己满意,博客技术更多是功能性的文字,先输出,解决实际问题更重要。

行动

不产生行动的经验是无效的,经历了这一次大问题,自己要做如下的几方面调整:

  • 建立测试环境
    • 建立起自己的博客测试环境,关于代码的挑战一定要在测试环境测试通过后再部署到生产环境。
  • 备份
    • 做主题的备份,改变原来的直接submoduel模式,保证主题的配置不会再出问题。
    • 自己的博客源码进行备份,本地和远程都要配置,保证出问题时能够及时恢复。
  • 研究问题
    • git submodule
      • submodule的原理,使用过程中的注意事项。我在使用中出现的几个问题的解释:为什么父仓库的变动会导致子仓库的消失。如果才能让子仓库不消失。如何同时更新父子仓库等。
    • git 修改没有保存工作区是否会丢失
      • 进一步搞清楚git的基本工作原理。
    • git merge的原理、冲突处理方法
      • 同上
    • hexo deploy的原理
      • 这个问题在下面详细说明。

未解之谜

部署失败的原因

hexo g -d执行后,在gh-pages或者coding-pages的分支上传了master中的所有代码,而不是自己需要的public文件夹下的静态网站的代码。在hexo-deployer-git中解释如下:

hexo-deployer-git works by generating the site in .deploy_git and force pushing to the repo(es) in config. If .deploy_git does not exist, a repo will initialized (git init). Otherwise the curent repo (with its commit history) will be used.

其中提到了如果前面的正常条件不能满足,就会把当前的仓库推送过去。这和自己遇到的现象是一致的,但是在什么情况下一定会出现这个现象呢?
我现在采取的变相解决办法是删掉git文件,重新新建git仓库,绕过了问题,还是没有答案。

如何在“科学上网”状态下访问自己的网站

自己能上Google的状态下,再次访问自己的网站就会出现403的报错,而Coding Net也无法在墙外访问。所以初步判断是域名解析的时候并没有指向自己设置的Github静态站点。目前也没有找到更合适的方法处理这个问题。

为何PV、UV数据不重新计算

在博客的底部“本站访客数XXX人次”和“本站总访问量XXX次”采用Next主题自带的不蒜子统计。这个统计原理是什么,为什么博客的文件都换了却依然能保证数据的连续性?其他的一些服务自己注册了账号,比较好理解,而这个服务并不需要注册账号,费解~

声明: 本文转载需标明出处,禁止用于商业目的。

ChangeLog

161121 新建