一夜之间，7.0万 Star，全部清零！

这又是不久前发生在开源圈子里的一件事情。

事件的主角正是一直以来被大家所熟知的开源全文搜索引擎 Elasticsearch Github 仓库。

具体是怎么回事呢？

原来就在某一天，有细心的网友突然发现，开源全文搜索引擎 Elasticsearch 位于 GitHub 上仓库的 star 数一夜之间突然骤降，从7万到几乎清零。

这还不算，甚至还有开发者发现连其 GitHub 仓库本身都直接来了一波 404。

就在事情发生后的不久，Elasticsearch 团队站出来公开澄清了这个问题。

原来事件的起因是来自于 Elastic 公司内部人员的一次误操作。

具体来说，就是 Elastic 内部在进行变更操作时，工作人员不小心将其 Github 平台上多个的公开Git仓库错误地标记为了私有。

这一操作导致广大用户无法访问这些 GitHub 仓库，不仅 Elasticsearch 仓库本身出现了“404”，连 Elastic 公司组织下的其他 GitHub 仓库也受到了牵连。

在发现问题后，Elastic 团队迅速响应，开始紧急恢复这些受影响的仓库状态。

在经过一系列的响应和沟通后，团队最终将所有受影响的仓库都恢复为了公开状态，并且恢复了所有分支。

然而，尽管仓库本身得以恢复，但仓库 star 数的损失却成了一个无法挽回的遗憾。

截止到写这篇文章时，距离事件发生已经有一段时间了，不过目前这个知名的 GitHub 仓库 fork 数有好几万，但是 star 数才回来一千多。。

看来这个数据又是恢复不了了？

不过这类事情其实也不是第一次发生了，其中比较为大家所熟知的就是发生在两年前的：

“HTTPie 事件”。

HTTPie 是一个现代的、用户友好的开源命令行 HTTP 客户端，它以其简洁的语法和人性化的输出格式而受到开发者的喜爱，使得执行 HTTP 请求变得轻松愉快。

HTTPie 项目的作者 Jakub 于 2012 年在 GitHub 上进行了第一次提交，到 2022 年一共积累了 5.4 万的star。

然而就是这样一个拥有 5.4 万 star的项目，当时也是因为作者的误操作，一夜间 star 数全部清零。

据作者描述，当时自己试图将这个项目的 GitHub 仓库从公共仓库设为私有仓库，结果弄巧成拙，导致数据丢失。

为了尽可能避免损失，事情发生后作者 Jakub 第一时间尝试与 GitHub 联系，希望 GitHub 能够帮助他们恢复原本的数据，不过 GitHub 那边却拒绝了作者的这一请求。

为此作者 Jakub 在 HTTPie 官博里还特地写了一篇文章，讲述了自己当时误操作的来龙去脉和心路历程，以及从中吸取到的教训。

所以聊到这里大家要注意，GitHub 之前一直有一个特性特别要注意，那就是如果一旦将原本是 public 状态的 GitHub 仓库设为私有，那该仓库对应的 Watcher 和 Star 数据就会被永久删除。

正如大家所讨论的，虽说像 Elasticsearch 这种顶级的开源项目现在也不需要这些所谓的 star 数、fork 数来证明自己，但是多年积累下来的社区数据一夜清零多少也是一件挺遗憾的事情。

通过这几次事件，也再次提醒我们，以后大家在操作自己（或者团队）的项目仓库时，针对每一步操作都要确认清楚，不能想当然贸然操作，多谨慎一些总是好的。

注：本文在GitHub开源仓库「编程之路」 https://github.com/rd2coding/Road2Coding 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。