阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 OSC开源社区（ID：oschina2013) 「Travis」欢迎转载，保留摘要，谢谢！

• 发生了什么？
• 为什么要设为私有
• GitHub 区别对待、拒绝恢复

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

不知道大家是否使用或了解过 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 数量。