10 年攒 5.4 万 Star 一键归零，开源作者：十分后悔

HTTPie是一款开源的命令行 HTTP 工具包，提供命令行交互方式来访问 HTTP 服务。

与其它同类型项目不同之处在于：为尽可能使终端的 API 交互人性化，HTTPie 是从零开始构建的。

自 2012 年 2 月 25 日发布第一个公开版本开始，HTTPie 团队就将项目托管在 GitHub 上了。Jakub Roztočil 解释道：“当我意识到自己的 API 测试结果可能会引起开发人员社区的广泛兴趣时，GitHub 作为代码托管平台，显然是个不错的选择。”

事实证明，Jakub Roztočil 的选择没有错：多年来，HTTPie 开发团队对项目不断改进，吸引了众多开发者的使用与好评， HTTPie 也因此逐渐成为了 GitHub 上最受欢迎的 API 工具，还是 GitHub 上最受欢迎的 80 个公共存储库之一，Star 数高达 54k+。

Jakub Roztočil 对这一成绩表示感恩：“这个不起眼的工具居然吸引了如此庞大的社区，真是令人难以置信， GitHub 在这之中发挥了重要作用。”

然而，就在 HTTPie 发展一切顺利、即将迎来在 GitHub 上托管十周年之际， Jakub Roztočil 的一个误操，令 HTTPie 这十年积攒的所有 Star 都凭空消失了。

Jakub Roztočil 懊恼表示：“ 我不小心将 HTTPie 项目的存储库设为私有了。”

54k+ Star 瞬间消失

那天，Jakub Roztočil 先是将自己的 jakubroztocil/jakubroztocil 设置为私有，即在其个人资料中隐藏了一个空的 README。随后，他只是想以相同的操作在组织资料中也隐去一个空 README 文件，不料却成为了“悲剧”的开始。

不知道是否有人注意到，在 GitHub 进行配置文件和存储库时，通过用户和通过组织的命名虽有不同，但非常相似：name/name（用户）与 name/.github.（组织）——这也就是 Jakub Roztočil 误认为自己在另一个零 Star 的空存储库中的原因：“ 我没有意识到命名存在不一致，所以我错误地选择了私有化 httpie/httpie 而不是 httpie/.github。”

（注：httpie/httpie 是拥有 54k+ Star 的项目存储库，而 Jakub Roztočil 本来想隐藏的是 httpie/.github。）

或许有人会问：那将项目再公开不就好了？不错，可问题是 GitHub 有一个“无情”的设定： 一旦将存储库设为私有，将永久删除其所有 Watch 和 Star。

也就是说， HTTPie 用十年积攒下来的 54k+ Star 一瞬之间就没了。

聊胜于无的“确认框”

按常理来说，手机里删个照片都会“温馨提醒”一下，对于这种具有较大影响的操作，GitHub 应该也会提醒吧？

“确实有一个确认框”，Jakub Roztočil 表示：“GitHub 会提醒你一句‘ 你将永远失去这个存储库的所有 Watch 和 Star’。”

可是，这个确认框的内容一成不变：不论是对于没有 Star、没有内容的存储库，还是面对具有十年历史、54k+ Star 的存储库，这个 确认框都几乎一模一样（只有最后一行的 httpie/httpie 和 httpie/.github 不同）——这对此前刚在其个人资料中顺利隐藏了一个空 README 文件的 Jakub Roztočil 来说，确认框的提醒作用聊胜于无。

一起来对比下面两张图，你能区分出哪一个是空存储库可以安心删除，哪一个会重置已拥有 54k+ Star 的存储库吗？

Jakub Roztočil 无奈表示：“提醒内容应更结合实际， 如果确认框中说‘你将失去 54k+ Star’，那我肯定会停下来。”

“双标”的 GitHub

可惜，以上分析及感想均产生于在“悲剧”发生之后。

彼时尚未意识到自己错误的 Jakub Roztočil， 在完成操作后看到组织页面的时候，陷入了无尽的茫然：为什么我想要隐藏的空 README 文件还在，最受欢迎的 HTTPie 存储库却不见了？

片刻之后，Jakub Roztočil 突然意识到发生了什么，火速回到存储库试图改正，可直到半小时后 GitHub 才允许： 这半小时中，GitHub 忙着级联删除 HTTPie 这十年来所有的 Watch 和 Star。

Jakub Roztočil 沮丧道：“我没有办法阻止这个过程，便开始发邮件给 GitHub 寻求支持，可最后也只能在 Star 数降为 0 后，再将存储库公开。”

事发之后，Jakub Roztočil 希望 GitHub 能利用备份帮助其恢复 HTTPie 54k+ Star 的社区，因为 GitHub 自己也曾发生过类似意外：GitHub 团队有次 不小心将 GitHub Desktop 应用存储库设为私有，随后没几个小时就恢复了包括 Star 在内的一切，当时 GitHub 前 CEO 还特地解释是 通过数据库备份恢复的。

但 GitHub 拒绝了 Jakub Roztočil 的请求，理由是这 会导致不良影响，甚至即便 Jakub Roztočil 表示愿意为此提供经济补偿，GitHub 也还是拒绝。

对此，Jakub Roztočil 总结：“GitHub 可以通过备份恢复私有再公开的存储库，但 前提是这得是他们自己的项目，而不是社区项目。他们最多给你发条推文呼吁一下。”

“GitHub 难道不该提供更好的用户体验吗？”

茫然过，慌乱过，无助过，也愤怒过，但最终 Jakub Roztočil 还是平静地接受了，毕竟一切已尘埃落定，54k+ Star 回不来了。所幸许多开发者在知情后纷纷重新点击了 Star，目前 HTTPie 的 Star 数也已达 4.5k+。（GitHub 地址：https://github.com/httpie/httpie）

“虽然我们的选择有限，但至少有一些经验教训想与你们分享。”Jakub Roztočil 在最后如此说道。

在撰写本文时，HTTPie 存储库再次开放，数据在不断上升中。

Roztocil 过去提到 GitHub 团队自己不小心取消了一个 GitHub 桌面仓库并恢复了 star，称 GitHub 有备份功能可以恢复未发布仓库的 star。当 Roztocil 要求 GitHub 恢复 HTTPie 星号时，GitHub 拒绝这样做。

“GitHub 通过将它们设为私有来恢复损坏的存储库，但前提是它是你自己的项目，而不是社区项目，”Roztocil 说。对于自认为为 GitHub 贡献多年的 Roztocil 来说，GitHub 的回应多少有点令人吃惊。

作为本案的经验教训，Roztocil 引用了以下内容：

1：私有操作时显示的对话框的UI设计
Roztocil 将 HTTPie 存储库保密的原因之一是他没有注意到警告对话框文本中的错误。从这一点出发，Roztocil 表示，“当用户试图破坏某物时，不要用抽象的语言描述潜在的场景”，并根据用户的操作在对话框中包含清晰的数值等。推荐。例如，在桌面版本的HTTPie中，删除空间时显示的对话框有一个机制来指定要删除的内容的类型和数量，如下所示。

2：数据库设计
为了能够避免不经意间误删除，硬删除（物理删除）会将数据从数据库中彻底清除，但

软删除（逻辑删除），在数据本身保留的情况下逻辑擦除数据。Roztocil 认为应该采用逻辑删除机制。此外即使采用硬删除，最好延迟流程执行，以便用户可以立即回退。

3：与GitHub的关系
在这种情况下，很明显 GitHub 没有对用户端的人为错误做出响应的法律义务。Roztocil 认为他与 GitHub 建立了 10 年的共生关系，但 GitHub 的回应并没有超出使用条款的范围。“我们继续希望 GitHub/微软（GitHub 的母公司）改变其机器化的态度，有朝一日恢复项目社区。” GitHub 拥有所有数据和它，我们有恢复的方法，我们希望 GitHub 改进其 UI 和数据库设计，以防止其他团队在未来做同样的事情。

此外，虽然 HTTPie 的Star已经丢失重建，但“HTTPie 会比以往任何时候都做得更好”，而且还在不断增长。Roztocil 表示，他期待在未来几周内发布新产品HTTPie for Web & Desktop （网站和桌面版本）。

这篇文章还出现在社交新闻网站 Hacker News 上，并引发很多人的评论。

@roger ：‘我不是在说最简单的‘摆脱粗心’的解决方案，通过在 GitHub 上强加责任来解决”，但这是“人为导致人为错误，事实并非如此”。

@artiser 反驳说：改进系统比期望提高注意力更好，GitHub 团队一开始就犯了同样的错误，在 GitHub 的规模上，每隔几周就会发生类似的事情。我无法完全控制用户行为，但向警报 UI 中添加信息至少可以帮助用户做出正确的决定。

@vaishnavsm：“我真的很喜欢这篇文章。虽然作者显然对他们失去了他的社区并且 GitHub 没有恢复它感到难过（老实说，所有人在类似情况下都会难受的），但他们也在关注未来，并用他们的个人经历作为我们所有人都可以学习的寓言。 作为设计师和开发人员，我们也将根据其建议改进我们的工具包。谢谢 HTTPie，你获得了一颗新 Star！”

@ghoomketu：“那个确认框的对比图真的很可怕，我看了两遍才发现最后一行不同。希望 Github 高层管理人员能尽快注意到这一点并加以改进。”

也有许多人终于在此刻 爆发了对 GitHub 的不满。

@sefrost：“GitHub 自己犯了完全相同的错误，却能通过数据库备份修复它，这确实不公平。”

@bsuvc：“当然，作者应该对此次失误负责，但 GitHub 难道就不该提供更好的用户体验吗？难道不小心私有化然后公开的存储库真的有必要清空其 Star 吗？这难道是项目作者和点击 Star 的开发者们想要看到的吗？”

参考资料：

https://httpie.io/blog/stardust

作者：场长

相关阅读：