不知道大家是否使用或了解过 HTTPie 这个项目，如果对它还不熟悉的话，这里先简要介绍一下：HTTPie 是一个开源的命令行 HTTP 客户端，它的目标是使 CLI 与 Web 服务的交互尽可能人性化。HTTPie 设计用于测试、调试以及通常与 API 和 HTTP 服务器交互。http& https 命令允许创建和发送任意 HTTP 请求。它们使用简单自然的语法，并提供格式化和彩色输出。

HTTPie 项目的作者于 2012 年在 GitHub 上进行了第一次提交，至今已走过 10 年时间。经过不断地迭代和改进，HTTPie 如今已经成为了 GitHub 平台上最受欢迎的 API 工具之一，并拥有超过 5.4 万 Star 和 1 千多 Watch。

这个拥有如此高 Star 数量的项目，却因意外导致 5.4 万个 Star 全部归零。项目作者 Jakub Roztocil 近日在博客中详细介绍了此次事件的来龙去脉，也顺便可以给其他项目的作者敲响警钟。

发生了什么？

Jakub 首先是承认了此次事件是由自己的错误操作导致的：

由于一连串不幸的事件，我不小心把项目的仓库设为了私有，这个操作让 GitHub 连带删除了我们花了 10 年时间建立的社区。

为什么要设为私有

作者 Jakub 表示：

把仓库设为私有就会永久删除所有 Watch 和 Star，这是 GitHub 的一个特性。我也知道这一点，因此我显然无意将 HTTPie 设为私有。

之所以会导致这样的结果，最直接的原因是 Jakub 以为自己在一个不同的仓库里面（该仓库没有内容也没有 Star），这是他在一周前创建的，但之前一直没有向里面填充内容。

Jakub 在当时并没有意识到仓库在命名上存在不一致，HTTPie 项目的仓库为 httpie/httpie，而 Jakub 想要设置的仓库为 httpie/.github。

这就是为什么我在没有意识到我的错误时，将 httpie/httpie 设为私有，而不是 httpie/.github

当 Jakub 做完操作回到组织页面后，他发现仍然可以看到空的仓库，反而是 HTTPie 项目仓库消失不见时，他才真正意识到发生了什么。于是 Jakub 立刻回到设置页面中想要重新将 HTTPie 设为公开。但 GitHub 在接下来的半个小时内都不允许他这样做，原因是 GitHub 正在 “帮助” 他删除仓库的 Star 和 Watch，无法中途停止这个过程。

GitHub 区别对待、拒绝恢复

为了尽可能避免损失，事后 Jakub 第一时间与 GitHub 取得联系，希望 GitHub 能够帮助他们恢复原本的数据。毕竟 GitHub 团队自己就曾经不小心把 GitHub Desktop 应用的仓库设置为私有，并在几个小时内就为自己恢复了一切。

当初 GitHub 的 CEO 对这一情况做出了解释：

开发人员今天早上错误地将 GitHub Desktop 仓库设为私有，重新修改回来并不会恢复它的 Star 和其他一些东西，因此我们正在从数据库备份中进行恢复。

显然 GitHub 对此是有相关备份的，并且能够通过备份挽回因不小心将仓库设为私有而造成的损失。但是在 HTTPie 项目的事件中，GitHub 却拒绝这样做，理由是会引发不良的副作用和浪费资源成本。Jakub 甚至向 GitHub 提出经济补偿，也同样遭到了拒绝。

虽然这件事是由于 Jakub 自己错误操作导致的，但他在博客中也提出了一些 GitHub 可以改善的地方，也希望其他项目作者能够避免再犯同样的错误。首先，他希望 GitHub 能够以更加清晰、明确的方式向用户告知操作的危害性，而不是一句放在任何地方都适用的 “警告：这是一个潜在的破坏性操作”；其次是改善数据库的设计，尽可能使用 “软删除”，并在一定时间范围内延迟 “硬删除”。

目前 HTTPie 已重新公开，截止完稿，该项目已获得 9 千多的 Star 数量。