缘起

2019 年底，我突发奇想想要自己统计一番 GitHub 上存储库的一些信息。尽管 GitHub 有自己的年度统计，我还是想试着自己爬取一下，说不定能挖出什么有意思的信息，何况这是我第一次有机会处理比较大量的数据，也算是一种学习的过程吧。于是花了一下午写了个简单的爬虫（时间都花在增加 Rate Limit 上了...），然后扔在了两台服务器上开始跑（GitHub  API 真是好文明）。

从 2019.11.21 3 时到 2020.1.12 24 时的 52 天 21 小时内，我的爬虫一共爬取了与 2,024,705 个用户有关^*的 14,651,923 个公共存储库的基础信息，平均每秒爬取 3.2 个存储库。据 GitHub 的官方数据计算，我爬取了大约 15% 的存储库信息，但由于封禁库和私有库的数量未知，我暂时无法确定我爬取的存储库占公共库的比例。同时由于存储库数量较多，基本可以认为爬取到的样本在时间尺度上已经足够随机，可以通过统计得出一般结论。

爬到自己了，合影.jpg

那么下面就来看看统计出来的一些结果吧。爬虫的技术细节和数据集下载放在文末。

* 指这些用户拥有至少一个库

统计信息

以下统计结果均基于已放于文末的数据集。由于爬虫爬取的时间跨度长，加上我并没有完整爬取 GitHub 所有存储库，因此我不能保证以下统计结果符合真实情况，各位可以下载数据集或自行爬取进行验证。

一些数据

¹ 基于用户 ID 规律合理推断
² 统计范围仅限于当前数据集

比较出乎我意料的是创建自 Fork 的存储库的占比。我预估这样的存储库占比不会太低，但没有想到能接近一半。此外单用户拥有最大库数量也大大超出了我的预期，pombredanne 这个用户名下拥有将近 24k 的存储库，不过绝大多数都是 Fork 来的，在情理之中。此外这个数据集中拥有最多存储库的账户其实是一个组织 gitpan，这个组织拥有 36,377 个存储库。

语言

首先必须要说明的是，在这个榜单中我排除了 HTML 和 CSS，因为在严格意义上它们不属于“编程语言”。如果把它们计算进来的话，分别有 640,368 个和 361,425 个存储库的主要语言分别是 HTML 和 CSS，这样在这份榜单中它们可以排到第 6 和 第 10 名。JavaScript 毫无疑问获得第一，第二名 Python 的热度则和 JavaScript 相差将近一半。此外还有 2,448,486 个存储库未能识别出语言，占比 16.7%。在上面的榜单之外，与机器学习和数据科学相关的语言还有 Jupyter Notebook 排名第 13，R 排名 20，Julia 排名 43。

说实话这份排名和 GitHub 官方的排名差别很大，除了前三名，后面的基本都不太一样。我的排名统计结果完全基于 GitHub 对于存储库的主要语言识别，加上我的存储库数据不完整，和官方的数据不同是很正常的，可以做一个参考，但大概率还是官方排名更加准确。

许可证

自 GitHub 推出许可证功能以来，拥有许可证的存储库比例升升降降，却始终没有超过一半。选择一个合适的许可证对项目的良好发展真的很有帮助，要了解如何选择合适的许可证，请参阅这篇文章。

对于拥有许可证的存储库，MIT 麻省理工许可证 总是占比最大的；第二则是 Apache-2.0 许可证。此外，WTFPL 许可证也挤入了前 15 名。

星标

Star 数量毫无疑问是一个存储库受欢迎程度的体现，而 Star 数高的项目基本上大家都了解过。截至爬取结束时间，GitHub 中 Star 数最多的库是 freeCodeCamp 非常完美的驼峰命名法，其次则是著名项目 996.ICU。Vue 现在的 Star 数已经稳压 React 一头，Vue YES! 此外 awesome 也挤进第七名。

由于 Star 需要时间积累，新项目的 Star 数量很可能是比不过老项目的，这就会导致有实力的新项目无法出现在榜单中。因此我还统计了日均 Star 数，试图通过日均 Star 数来反映项目受欢迎的程度。由于正热门的项目会比老牌热门项目有优势，这一项的统计范围是 2020-01-01 之前的所有存储库。996.ICU 和 freeCodeCamp 再次出现在前 10 名，而最近的热门项目 wenyan 则飙升至第 2 名。此外还有 BullshitGenerator，即最近热门的“狗屁不通文章生成器”和 evil-huawei 分列第 3 和第 5 名。

说实话这个曲线比我预估的陡多了。你可能已经注意到了，这个图表的横轴不是均匀缩放的，实际上曲线要比看起来陡很多。同时受爬取方式的影响，GitHub 中 Star 数较少的存储库数量远比我爬取到的多。也就是说，实际情况下曲线远比这个图表上的陡。拿点 Star 不容易啊。

名称

终于知道了原来存储库的名称是有长度限制的...尽管最长有 100 位，大部分人还是喜欢 8 位长的存储库名。此外 1 位长的名称也比我预估的要多一些。举几个存储库名称长度为 100 的例子吧。

• testing-something-elsetesting-something-elsetesting-something-elsetesting-something-elsetesting-some
• acts_as_validated_config_so_app_will_not_run_in_random_situation_and_qa_gays_will_not_cry_to_you_whe
• ............................................________-....................................-.---......
• ----------------------------------------------------------------------------------------------------
• nyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyannyan

...创造力有够丰富的。

最近 GitHub 上有一种奇怪的风气，那就是建立 Awesome 合集骗 Star。看起来 Awesome 存储库满地都是，甚至还出现了关于 Awesome 的 Awesome 合集这种迷惑行为。于是我统计了一下，还好，占比才 0.5% 不到，Awesomer 们任重而道远呐。

尽管要在 github.io 上托管网站，存储库不一定要以 .github.io 结尾，但我还是统计了一下。拥有这类存储库的用户比我预想的要少一些，看来还有很多人没有完全发挥 GitHub 的完整实力啊（比如我 Doge）。同时这类存储库在所有存储库中占比 1.12%，看起来不多，不过至少比 Awesome 多。

看得出来 GitHub 对于用户名长度的限制是 1-40 位。用户名最短的 27 位占据了 A-Z 外加 - 的所有可能，而用户名最长的则是一个组织 UOIT-RESEARCH-database-information-group。不知道是巧合还是某种规律，最受欢迎的用户名长度和存储库名称长度一样，都是 8，有点意思。

创建时间

由于我并没有完整爬取所有存储库，我只能以相对值来统计每月新增存储库数量的变化趋势。在这个图表中，我将 2017-09 的数据设为了 100%。你一定一眼就能注意到 2017 年 6,7,8 月的“一柱擎天”。我第一次看到这个数据的时候的确愣了一下，不过就着这条新闻看就能明白为什么了：2017 年 6 月微软收购 GitHub。

重新确认了一下，微软收购 GitHub 比这个高峰晚了一年，目前我对这个高峰没有什么很好的解释，如果你有什么思路的话欢迎评论。

需要注意的是这张图表中我排除了 Fork 存储库，因为 Fork 存储库在 API 中的创建时间是原始存储库的时间，会影响整体趋势。此外，GitHub 中还有一个创建于 2007 年 10 月 29 日的存储库，那就是 id: 1 的...

而它的创建者正是 GitHub 的创始人之一 Tom Preston-Werner。

一些有趣的结果

当初打算自己爬的目的之一就是想看看能不能挖出什么有意思的信息，结果真的有一些不挖不知道的信息。

奇怪的存储库

在爬取到的所有存储库中，有 3 个存储库是“无主”的，即它们的 owner 属性为空。这三个存储库的基本信息如下。

更奇怪的是这三个存储库“无主”的情况还不一样。第一个存储库可以通过 /repositories 这个 GitHub API 找到， 这个链接中的第一个存储库就是它；而其余两个存储库甚至无法在 /repositories API 中找到。不过就算能在 API 中找到第一个存储库，它的 html_url，即 https://github.com//vscode-redprl 仍然是不可访问的。这可能是 GitHub 早期的一个 Bug 导致的，不过我仍然对爬虫是如何找到这三个存储库的以及这些 Stars 是哪里来的感到好奇。

奇怪的用户名

在爬虫爬了一段时间以后，API 中突然开始出现大量的以 fdp 开头的 18 位乱码作为用户名的用户。这些用户拥有的存储库和 starred 的存储库都为 0，而他们的 html_url 为 404。以下是几个例子。

• fdpEpolGCEdQX4ZlRJ
• fdp8XaVrdtmDZnO5pR
• fdp8XRAGnwAOkTr2Ya

由于我的爬虫并没有超过 Rate Limit，所以我排除了这是污染数据的可能。我怀疑这可能是某种 Bot 账户，于是一边更新爬虫过滤掉了这些用户，一边给 GitHub 支持发邮件问了具体情况。过了两天 GitHub 回复我说这些是被自动判为可疑进而被封禁的用户（原话是 they have been flagged by our automated measures for detecting suspicious behavior）。想到我正在疯狂爬取 GitHub，突然害怕.webp

行吧。

技术细节

爬虫使用 Python3 编写，数据库使用 MySQL。爬虫共使用了 4 个 API Token，在两台服务器上分布式爬取。爬取思路为：

1. 通过 /users API 遍历用户，每个请求最多获取 30 个用户信息
2. 循环 30 个用户，分别获取 /users/<user_name>/starred 和 /users/<user_name>/repos API 中的存储库信息，每个请求最多获取 100 个存储库信息，超过 100 个的分页获取
3. 提取存储库信息，插入数据库。对于已存在的存储库，更新数据
4. 获取下 30 个用户信息

由于爬取过程中我多次调整了爬虫逻辑，爬虫爬取到的用户 ID 区间并非连续的，具体区间为1-839586, 14800001-14885493 及 28965251-31161101。

免责声明

本站会尽可能地提供准确信息，但本站不对此文章中信息的准确性和即时性及带来的任何影响负责。

本站不代表 GitHub 官方，本文仅供学习之用，请不要将本文内容直接用于任何商业项目中。

数据集下载

导出的 SQL 文件大约为 1.38GB，全部放在了 GitHub 上（在危险的边缘试探.webp

此外我也提供了 MEGA 下载，链接在这里。