写技术博客，出发点无非是：
- 梳理自己的知识体系
- 通过博客与外界交流
为了更好的管理和写作，我们很有必要学习一下 Projects。
Github 项目管理模式——Projects
Issues
Github 中传统的项目管理是使用 issue 和 pull request 进行的，这部分内容不是本文重点，不再赘述。 但有一些功能需要提及：
-
Tag： 每个 issue 可以添加不同的 tag，可以用于标记 issue 的种类和 issue 的处理进度； -
MileStone：每个 issue 只属于一个 milestone，用于显示 issue 的处理进度。
Projects 概述
关于 Projects GitHub 已经给出了详细介绍：
Projects 提供了真正的管理 issue 的能力；而传统的 tag 方式只能以手工的方式管理分类（如 Q&A，bug，duplicate，feature 这些标签🏷），或者以手工的方式管理 issue 进度（need test, in progress, wait approval 等这些标签）。
不过在开始讨论这个之前，有必要先讨论一下看板。
看板（Kanban）
需要详细了解的请看 Wiki。所谓看板，就是把一块木板上分成几列，然后在每一列上贴上不同内容的卡片。 木板上的这几列一般是有顺序的，卡片可以在不同的列之间移动来表明所处的状态。
创建步骤
下面我们进入操作阶段。
1 创建 Projects
为了更好的管理和分类，我先是创建了一个组织：
进入新创建的组织，并点击：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 ↩
