我认为更好的管理github pages blog

使用jekyll也有好几年了,说实话其实jekyll + markdown的方式真的没有cnblogs等这种专门的平台来的方便。至少纯粹从写blog的角度出发,在目前的互联网用户体验大环境下,冷静思考这种方式,真的挺差。

以前,在改blog风格之前,因为没有使用jekyll的plugins,所以我还是启用了github pages服务的jekyll服务。但是这次因为图片管理的这个plugin,已经不能再启用github pages的jekyll服务了(因为github禁止第三方的plugins),所以只能启用直接嵌入静态文件的方式来执行。那么问题就来了,整个站点的site是目录和站点的原信息目录,到底怎么解决它们之间的问题?


更多的做法

我也搜了一下,更多的做法是这样的:

  1. 在github上开一个project作为pages服务的project;
  2. 在这个project上开启一个分支gh-pages,因为这是github默认的blog服务分支;
  3. 当你写blog的时候,checkout到master分支,然后开始写,写完后build;
  4. checkout到gh-pages分支,将master中的site目录合并到当前分支;
  5. commit gh-pages分支,再commit master分支;
  6. 结束

这也是一种办法,但是对于我来说受不了的是:一个目录中文件有冲突。一个文件夹存在了多个功能,区分这些功能的办法竟然是我们使用git的分支来达到目的。虽然这样也可以,但并不能有效的去解决一个问题,或者说我一直要check一个问题:就是我当前到底在哪个分支下?显然,对于有神经质的我来说,这种办法明显不切实际。


我喜欢的办法

  1. 一个目录就一个用处,多个功能我宁愿开多个目录;
  2. 不要把功能都合并到一起,显然这样在日常维护中很难执行,能分即分开;
  3. 做事的流程要分开,比如我写blog的时候,我就只要照顾到写blog就可以了,当我准备发布的时候,我只要照顾到发布就可以了。两者之间不要切换来切换去;
  4. 自动化,比如发布,最好是一个脚本直接搞定;

所以我重新设计了一种办法:

  1. 将上面的一个文件夹管理一个blog的方式直接换成2个文件夹,一个只管source的源信息目录,一个管理静态站点,也就是元信息build后生成的site的文件夹;
  2. 因为blog本质上变成了2个文件夹,所以github上也直接申请两个project,一一对应;
  3. 调试blog可以在source中进行,source中完成后,cp其中的site目录到我们的静态站点目录;
  4. 直接commit两个project到github即可;

所以有了这样的一个流程脚本:

cd 94geek #切换到静态站点proejct
git checkout gh-pages #确保目前在gh-pages分支,github只支持这个分支
cd ../source/ #切换到源目录
rm -rf  _site #删除上一次的site目录
jekyll build #编译当前的source
cp -rf _site/* ../94geek/  #cp当前次生成的site到静态project
git add ./ #加入更新的blog
git status #查看一下当前的状态对不对
git commit -am"upload log" #提交,这里信息被写死了,其实你可以使用参数来指定
git push #同步到github
cd ../94geek #切换到静态project
git add ./ #加入新增的blog静态文件
git status #查看当前静态project的状态
git commit -am"update blog" #提交
git push #同步

将这个文件放入静态project和source同等级目录下,每次写完blog后只要简单的执行这个脚本即可。


总结

这种方式有几个好处:

  1. 清晰:目录和功能各司其职;
  2. 简单:写blog和发布没有任何的确认,其实只要管理好source就可以了,别的都是自动执行;
  3. 统一:写blog和发布blog不混乱,各管各的,不需要分心来处理;

关注我的微信公众号