如何用 Github Projects 写技术博客？

2018-11-26 本文已影响1人水之心

写技术博客，出发点无非是：

梳理自己的知识体系
通过博客与外界交流

为了更好的管理和写作，我们很有必要学习一下 Projects。

Github 项目管理模式——Projects

Issues

Github 中传统的项目管理是使用 issue 和 pull request 进行的，这部分内容不是本文重点，不再赘述。但有一些功能需要提及：

Tag：每个 issue 可以添加不同的 tag，可以用于标记 issue 的种类和 issue 的处理进度；
MileStone：每个 issue 只属于一个 milestone，用于显示 issue 的处理进度。

Projects 概述

关于 Projects GitHub 已经给出了详细介绍：

Projects

Projects 提供了真正的管理 issue 的能力；而传统的 tag 方式只能以手工的方式管理分类（如 Q&A，bug，duplicate，feature 这些标签🏷），或者以手工的方式管理 issue 进度（need test, in progress, wait approval 等这些标签）。
不过在开始讨论这个之前，有必要先讨论一下看板。

看板（Kanban）

需要详细了解的请看 Wiki。所谓看板，就是把一块木板上分成几列，然后在每一列上贴上不同内容的卡片。木板上的这几列一般是有顺序的，卡片可以在不同的列之间移动来表明所处的状态。

创建步骤

下面我们进入操作阶段。

1 创建 Projects

为了更好的管理和分类，我先是创建了一个组织：

New organization

进入新创建的组织，并点击：Projects

按照上图 1 标示的黄色数字顺序创建。按照提示输入一些相关信息，然后进入创建好的分类，创建栏目

新建Issues，并且选择对应的标签 Lables，分类 Projects

添加到 Projects 卡片

打开对应的 projects，往专栏中添加新建的 Issues（点击 Add cards，直接拖拽)

2 项目的 README.md

可以在 README.md 里面写一些简介，链接到具体的 Project 目录。

可以这样整理知识体系

Evernote：知识收集的仓库（使用浏览器剪辑的插件）
Github Issues：对遇到问题的整体解决思路进行梳理

发现，如果没有把 Evernote 的知识碎片整理成文，以后遇到同一个问题，就可能需要再次耗费精力在知识碎片中找。
现在 Github Issues 上会记录比较具体的解决问题过程，然后在Github 上写的文章，我平时一般也会同步到简书上。
最后，附上一个不错的Github博客地址https://github.com/johnnian/Blog，有兴趣的可以进去看下^[1]

知乎上如何有效地使用 GitHub？亦做了十分好的补充！

作者：Johnnian 链接：https://www.jianshu.com/p/7c2cce028d29 ↩