這又是不久前發生在開源圈子裏的一件事情。
事件的主角正是一直以來被大家所熟知的開源全文搜索引擎 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 數來證明自己，但是多年積累下來的社羣資料一夜清零多少也是一件挺遺憾的事情。
透過這幾次事件，也再次提醒我們，以後大家在操作自己（或者團隊）的專案倉庫時，針對每一步操作都要確認清楚，不能想當然貿然操作，多謹慎一些總是好的。
