GitHub 越来越有名，很多同学都把它作为一个关键字加入自己的简历当中。不过我在面试中，问到如何使用 GitHub，对方通常会答复：上去看源码呀！这个答案完全无法让我满意，具体的原因，一方面可以参考我之前的一篇文章《谈学习：读源码》，源码不是小说，直接看源码收获太小。另一方面，看源码是一个太直接的逻辑推断——上面有源码所以我去看源码——我不认为这是一个细心耕耘慢慢养成的习惯。
接下来我想简单谈一下，我认为应该如何使用 GitHub。
Issues 和 PR
一个 GitHub 仓库可不仅仅是一份源代码那么简单。GitHub 是开发者社交平台，所以每个项目在代码之外，都会有两个非常重要的模块：
- Issues 问题，包括 Bug，和其它使用者希望有的功能
- Pull Requests（PR） 其他的开发者在这个项目上做出了一些改进，或者修复了一些 Bug，希望能够合并到 master 当中，就会发起 PR
完美的代码是不存在的，越是用的人多的库，存在的问题，或者说被发现的问题可能就越多。阅读其他人提的问题，很多时候可以获得不小的收获，比如，大家开发时都遇到了什么问题？有没有与我类似的情况？他们是怎么解决的？大家最想要的新功能是什么？有哪些值得关注？我能做什么？等等。
以及，可能是更重要的，我们应该怎么样通过 Issues 与仓库的原作者进行交流。
毕竟我们每个人的时间都是有限的，对于大部分开源的类库来说，了解怎么用、有哪些问题、怎么避免踩坑，通常会比你知道它某个函数是怎么写的更有价值。
看文档
好的开源类库通常还会有一个做得非常到位的地方，便是它们的文档，做得通常详尽有价值。通过阅读文档，可以很快的了解这个仓库是干嘛用的，应该怎么用，能解决哪些问题，以及接下来，它的发展方向是怎样的。
据我观察，文档通常分布在三个地方：
- README.md，也就是打开仓库页面，默认渲染在文件列表下面的那块
- 官方网站，通常在导航下方，仓库简介那里
- wiki，通过导航链接可以到达
观察提交频率
并不是所有的仓库，都有开发者在进行积极地开发和维护。如果搜索到几年前的文章，被导引到一些比较古老的仓库，可能出于某种原因，已经没人对它进行维护了，这个时候，该放弃就要放弃。
人生苦短，时间有限，总会有更具价值的仓库供我们学习。
GitHub 热门趋势
GitHub 还有一个热门趋势页面，从中你可以了解到全世界的开发者都在关注哪些仓库，你可以把自己感兴趣的那些加星标记一下，将来不定时的翻一翻看一看它的 Issue、PR 和文档，通常都会有不小的收获。
GitHub Pages
GitHub 还提供给我们一个非常好的静态网站空间，完全免费，全世界都有 CDN，不用白不用。便是传说中的 GitHub Pages。
我们可以用它写博客，做笔记，重点是内容完全可以进行版本管理。
具体做法请自行 Google。
不要放弃提交自己的仓库，也应积极向别的开发者提出 Issue 和发起 PR
我觉得这件事和写博客一样，如果你只是在纸上记笔记给自己看，那多半会不求甚解；但是你想到写成博客总会有人看到，那多半还是会把要写的内容搞清楚，写全面，逻辑清晰可自洽。所以写博客是比记笔记更好的学习方法。以此类推，把自己的仓库推到 GitHub，也理应也是比在本地练习更好的学习方式。
这里绝不鼓励大家乱来，相反，我希望大家对自己的行为负责，重视 Issue 和 PR，毕竟都是提给其他开发者的，或多或少都会对别人造成影响。所以在提之前，十分有必要阅读仓库主人的提交须知，按照对方的代码规范书写代码，写好相关测试，然后再提交。做到言之有物，切不可乱来画猫。
总结
这篇文章不是传授大家应聘技巧的，而是希望分享自己的一些经验，让大家能够通过 GitHub 这个世界上最大的代码托管平台，正确的学习开发技巧。
如果您有相关的经验技巧，欢迎交流。
欢迎吐槽，共同进步