用 Github 搭建静态博客太繁琐?用这个小工具实现「傻瓜式」发布

用 Github 搭建静态博客太繁琐?用这个小工具实现「傻瓜式」发布
除了作为程序员们共享与协作的渠道,GitHub 一同也是一个绝佳的常识共享渠道。特别近几年静态博客逐渐鼓起,凭借 GitHub 的 Pages 功用保管个人博客成为了经济实惠、广受欢迎的一种计划,少数派此前也有许多文章介绍怎么依据 Jekyll、Hexo 等东西将内容布置到 GitHub 上的办法。 在尝试了 WordPress、Typecho 等许多建站东西后,现在我也决议回归静态博客。而和以往不同,这一次我认真总结了运用各个博客体系时遇到的问题与探索出的一些技巧,把这些经历糅合在一同,最终的作用便是这篇文章的主角:一个名为 Maverick 的静态博客生成器,以及一套依据 Maverick 的博客写作主动化流程。 凭借这套流程我完结了这些作用: 便当的图片办理 博客版别办理 在任何设备上写博客,包含浏览器 无需值守的主动化构建 免费、超快的全球 CDN 不需求在本地装置 NodeJS 这类运转环境(若要在本地写文章,需求装置 git) 若把 Markdown 文本和引证的图片比作面粉、鸡蛋,要把它们做成可口的蛋糕(静态博客),一般来说还需求一间厨房(比方你的电脑)以及一个烤箱(比方 Hexo)。在本文中我运用了 GitHub 供给的主动化服务 GitHub Actions ,使博主可以专注供给更优质的「质料」而不必操心「烤制」的进程 —— 在这儿,GitHub 充当了厨房与烤箱的人物。 大致思路 本文首要扼要介绍运用 GitHub 写博客以及自己写生成器的若干原因。为防止枯燥乏味,我将经过一个逐渐教程向咱们介绍这个流程的操作办法,交叉一些基本概念的解说。 为什么要运用 GitHub 写博客 除了免费、安稳之外,运用 GitHub 写博客还有许多优点。 GitHub 的中心是 git,一套专业的版别办理体系。不限数量不限时刻的版别回溯功用让内容办理十分便当;保管至 GitHub 上更是让安全性上升了一个等级。许多人写博客的不注重这一步,总爱把源文件放在电脑上某个随意的旮旯,或许直接发布到博客程序中而不加备份。 依我看这都是没有远见的做法。一旦坚持得久了,老旧的文章便是一笔财富;但电脑会坏,服务器或许被误操作删库,这都会形成无法挽回的丢失。 除文本内容外,对图片等附件的办理也是适当扎手的问题。因为 Markdown 才能有限,人们倾向于把图片上传至第三方图床,然后在文章中经过链接引证。然而这算不得牢靠的计划。今年年初就因为新浪忽然对自己的图片服务增加拜访约束,一众运用新浪图床的博主都只能叫苦连天。最好的办法是确保 Markdown 文本文件与图片文件坐落同处,文章内经过相对方位(例如 ./images/1.png 这样的链接)引证图片,自给自足,以最大程度确坚持久性与可拜访性。 许多人或许没有意识到,GitHub 本身便是一个优异的带有 Web 界面的内容办理体系(CMS)。一个博客体系应该有的功用,比如对内容的增修改查,GitHub 都能轻松做到;经过将库房克隆到本地,还能自在运用其它优质的编辑器进行写作。 这个进程没有繁琐的仿制、导入、导出,其体会是共同且接连的 。 此外,GitHub 是十分敞开且灵敏的渠道,从下文你将看到运用这个渠道所供给的的主动化解决计划(GitHub Actions),写博客、发布博客这件事可以做到多么简洁。 为什么我要自己写一个生成器 当然是因为现有的生成器,例如 Jekyll 和 Hexo 等,都多多少少有些不太便当的当地。 现有的生成器大多会要求将源文件以必定的目录结构放在指定的方位,例如生成器目录下,此外它们不太能处理经过相对链接引证图片的情形。以我上一年写的文章 运用 Travis CI 主动生成与布置 Hexo 博客 为例,便不得不将生成器本身也归入 git 版别办理,真实算不得高雅的解决计划。 Maverick 也是针对 Markdown 文本的静态博客生成器,可是与 Hexo 等有几点不同。 首要,Maverick 不约束源文件的存储方位 ,你可以把文章目录放在电脑上的任何途径下,例如 Dropbox、iCloud Drive,以便备份、同步、版别办理,以及在任何设备上用任何编辑器写作。 Maverick 也不约束源文件的安排结构 ,你可以依照你喜爱的办法安排它们,按时刻、按类别都可以。以 Hexo 为例,它要求把文章存储在 hexo目录/source/_posts 这个途径下;而此刻我运用 git 办理自己的博客源文件,目录结构如下: ![我的博客源文件目录](./assets/2019–12–23 10.05.57.png) 此外是对图片的处理,Maverick 答应在 Markdown 文件中引证 任何方位的图片,而且都能在生成网站时适宜地处理它们。若你在原始文本中经过肯定途径或许相对途径引证本地图片,Maverick 会在生成网站时主动寻觅它们,把它们仿制到一致的方位,并对应处理引证链接;若经过 URL 引证了长途图片,则(可选地)可以将它们下载到本地缓存,按本地图片对待。 在 Hexo 与 Maverick 中别离新建一篇文章,内容如下: ## 经过网络链接引证![](https://cdn.jsdelivr.net/gh/AlanDecode/site-Blog@gh-pages/archives/assets/13452d991bfec0ed426cd0615bc53703.png)## 经过相对方位引证![](./images/Mononoke_Hime.jpg)## 经过肯定方位引证![](C:/Users/Alan/Documents/Projects/Maverick/test_src/images/IMG_0005.jpeg) 别离履行生成,看看作用: Hexo 可见 Hexo 不能处理经过相对与肯定方位引证的图片,发布后的网页占用依然坚持本来的引证链接; Maverick Maverick 则能主动查找并将本地图片随网站发布,这使咱们能更自在地刺进图片。 此外,Maverick 支撑很多静态博客生成器应该有的功用,例如 RSS 源生成、 实时查找、Sitemap 等;此外还包含了扩展的 Markdown 语法,供给代码高亮、行内脚注、数学公式、图片排版等常用功用。你可以在 这儿 看到示例页面。 尽管现在还没有完结插件功用,但应该能满意个人博客需求。 现在,跟我一同着手实践吧 依据我 的实践,我将整个流程做成了一个 ,请将这个库房 fork 到自己的账户下(点击右上角的 Fork 按钮),然后跟我一同完结余下的过程吧。 fork 之后请暂时不要更改库房称号,坚持 Blog-With-GitHub-Boilerplate 不变。 为库房敞开 Pages 服务 进入新 Fork 的库房,点击右上角的 Settings 按钮,找到 GitHub Pages 相关设置 ,将 Source 设置为 gh-pages branch。 稍等片刻你就可以经过相似 https://.github.io/Blog-With-GitHub-Boilerplate 这样的链接拜访示例网站了。 尽管许多人知道可以把网站发布到 GitHub Pages 上,对背面究竟发生了什么却不甚了解:库房设置好 Pages 服务后,GitHub 为对应的库房分配一个链接,当运用这个链接拜访时,GitHub 就将详细的恳求映射到库房中的某个文件。例如 https://.github.io/Blog-With-GitHub-Boilerplate/index.html 这个链接,对应的文件则是库房根目录下的 index.html 文件,因为咱们都用 index.html 这个文件名,因而也可以省掉不写,其它链接同理。 现在,GitHub 上的一切库房都可以敞开 Pages 服务。库房分为两类: 第一类,库房名形如 .github.io 。敞开 Pages 服务后可以直接经过 http://.github.io 拜访。 第二类,其它称号的库房。对这些库房,敞开 Pages 服务后可以经过 http://.github.io/ 拜访。 两类库房都可以指定布置的内容来历,包含: master 分支(默许) master 分支中的 docs 文件夹 gh-pages 分支 这两类库房都可以绑定自定义域名,办法相同,在发布来历中创立 CNAME 文件或许在设置中绑定就行。此外, 私有库房也可以敞开 Pages 服务,这十分合适用来发布博客,设想在 master 分支中存储源文件,是只自己可见的;将生成的网站发布到 gh-pages 分支,是大众可见的。这是兼具安全与快捷性的计划。 为库房增加一个 token 为了后续可以经过 GitHub Actions 主动更新你的博客,咱们需求为库房增加一个 token。点击 这个网址 ,点击右上角的 Generate new token,起个姓名并勾选 repo 复选框: 点击页脚的 Generate Token,新的 token 会显示出来,把它仿制下来,保存好。关了这个页面你就永久也看不到它了。 回到库房中,进入 Setting,坐标找到 Secrets 选项卡,新建一个名叫 PERSONAL_TOKEN 的 secret: 在这儿,我扼要介绍什么是 GitHub Actions 。 回忆咱们的需求,是在库房呈现更改时主动更新构建与布置博客。其实,监督库房并在有改动时主动履行一系列动作是十分广泛的需求。软件开发工作中,常常需求对新增加的代码随时进行测验,或许进行布置,都是经过这样的主动化流程完结的。实际上这类服务还有个{{专门:不可思议}}的姓名:「继续集成(Continuous Integration)/ 继续布置(Continuous Deploy)」,简称 CI/CD。 此前,最广泛运用的 CI 服务当属 ;现在 GitHub 也推出了自家的 CI 服务 。相比起 Travis 来,GitHub Actions 愈加 「native」,经我测验好像也更灵敏、快速;此外,还能直接引证他人写好的规矩。本文就依据 GitHub Action 描绘构建流程。当库房收到新的更新(push)时,GitHub 会依据库房中 .github/workflows 文件夹下的 YML 配置文件发动 CI 流程。

Author: admin

发表评论

电子邮件地址不会被公开。 必填项已用*标注