GitHub 上 README 和 Issues 的入门协作法
· 阅读需 2 分钟
很多人刚用 GitHub 时，会把它理解成一个线上代码仓库：能 push、能 clone、能看文件。但到 2013 年，越来越多人开始意识到，GitHub 真正方便的地方不只是托管代码，而是围绕项目的协作信息也能被放到一起。
README 不是装饰，它是项目入口
别人第一次点进仓库，最先看到的通常就是 README。一个实用的 README 不一定很长，但至少应该回答几个基本问题：
- 这个项目是干什么的
- 怎么启动
- 依赖什么环境
- 当前做到什么程度
如果这些信息没有写清楚，别人就算把仓库 clone 下来，也很难快速理解项目状态。
Issues 的意义是把讨论留在项目旁边
过去很多小项目的沟通还停留在聊天窗口、邮件或者论坛回帖里，信息分散，过后很难追溯。Issues 的价值就是把“问题、建议、待办”直接挂在仓库边上。
比如一个很简单的流程：
- 提出问题
- 在 Issue 里补充复现方式
- 修复后关联提交
- 关闭 Issue
这一套并不复杂，但它会让项目记录第一次开始变得有上下文。
小项目也值得早点这样做
有人会觉得只有多人协作才需要 README 和 Issues，其实个人项目也很需要。因为时间一拉长，连你自己都会忘记当初为什么这么写、哪些地方还没做完。把这些东西写在仓库里，本质上也是给未来的自己留说明。
不必追求“像大项目一样完整”
2013 年很多开发者刚接触 GitHub，最容易犯的一个误区就是想一口气学完整套开源协作流程。其实没必要。先把 README 写清楚，再把明显的问题放进 Issues，已经能让仓库从“代码堆放处”升级成“可交流的项目空间”。
小结
GitHub 的价值从来不只是把代码放到网上。README 负责说明项目，Issues 负责沉淀讨论，它们一起构成了协作的最小闭环。对那个阶段的开发者来说，把这两个入口用起来，往往比多背几条命令更实际。