使用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一个问题：就是我当前到底在哪个分支下？显然，对于有神经质的我来说，这种办法明显不切实际。
我喜欢的办法
- 一个目录就一个用处，多个功能我宁愿开多个目录；
- 不要把功能都合并到一起，显然这样在日常维护中很难执行，能分即分开；
- 做事的流程要分开，比如我写blog的时候，我就只要照顾到写blog就可以了，当我准备发布的时候，我只要照顾到发布就可以了。两者之间不要切换来切换去；
- 自动化，比如发布，最好是一个脚本直接搞定；
所以我重新设计了一种办法：
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不混乱，各管各的，不需要分心来处理；