?作者 | codingwoman

譯者 | 布加迪

策劃 | 言征

大家可能都會面臨這樣直冒冷汗的情形：在使用Git進行版本控制時不小心推送了重要的密鑰或超大文件？要知道，在敏感數據公開暴露20秒后，再去刪除這些密鑰可能已經為時太晚了！

人非圣賢，孰能無過？本文會分享介紹幾個筆者在用的好技巧，這樣在Git時，再也不用擔驚受怕了。

一、永遠不要推送非必要的文件和信息

Git中一類不需要的內容是非常大的文件。如果不小心提交了一個大文件到存儲庫，這肯定會限制你拉取或推送文件所需的時間；如果文件大于100MB，甚至還會顯示錯誤。

其次，作為軟件開發圈中的一員，這個忠告應該聽過很多次：永遠不要將機密信息推送到存儲庫。擁有芝麻粒大點資源的攻擊者就可以通過竊取泄露的密文（secrets）和密鑰來危及許多GitHub用戶。然而，許多同行卻對此不太當回事。

因此，我想分享幾個統計數據。

我能進行另一個提交后刪除它嗎？

不。事實上，這比剛才的那件事還要危險。不要天真地以為，當他們從存儲庫中刪除文件后，文件再也訪問不了。這正是Git的用途所在。它會跟蹤你的文件版本歷史記錄，以便你在想要恢復更改時可以恢復。

通過以下列方式進行提交以刪除文件，你無異于將網上的陌生人引向存放密文的位置。

$ git commit –m “Remove api key”

只需你搜索一下，就可以看到這有多頻繁。更明確地說，截止2023年1月5日筆者撰寫這篇文章期間，在GitHub上搜索查詢“remove api key”，返回了100萬+提交，查詢“remove password”返回了735K+提交。

隨著ChatGPT大行其道，人們試圖編寫Python腳本來試用它，我發現無數的OpenAI API密鑰散布在GitHub的各個角落。

這將引發嚴重后果！

二、那該怎么辦？

當我們考慮從Git歷史記錄中刪除提交時，首先想到的是立即將分支的頂端更改為舊的提交。這使我們安全地回到密鑰不存在于存儲庫中的時候。

1 $ git reset <SHA1>
2 $ git commit -am message
3 $ git push -f <remote-name> <branch-name>

1.但已有一段時間了，是否為時太晚？

好吧，如果你遇到的問題與大文件有關，總是可以使用git filter-branch從歷史記錄中刪除過去的信息/文件。此外，還有一個極好極簡單的方法，我常常使用它。

見識一下BFG-Repo-Cleaner！這是一個用Scala編寫的工具，可以刪除大文件（比如預訓練的模型或無法丟棄的大PDF文件）或麻煩的blob（比如API密鑰、密碼和密文），其功能就像git filter-branch，但速度更快。

GitHub的官方推薦也建議使用BFG-Repo-Cleaner來清除文件。

說明：我最近被告知git filter-branch已被棄用。現在可以使用git filter-repo或直接使用上面提到的BFG工具。

2.可以松口氣了嗎？

不，還不能松口氣。當然，你可以隨時使用這個工具刪除大文件。然而，在將不必要的憑據推送到公共存儲庫之前，仍然應該小心為好。如果你最近在GitHub上泄露了密文，應該盡快用上面提到的工具收回密文。

此前，有一篇名為《Git會有多糟糕？揭秘公共GitHub存儲庫中的密文泄露》的論文首次全面深入分析了GitHub上的密文泄露。研究人員在文中評估了兩種不同的挖掘密文的方法：一種能夠實時發現99%的新提交的含有密文的文件，另一種利用了覆蓋13%的公共存儲庫的大快照，其中一些可以追溯到GitHub創建時的快照。

• 你認為大多數被發現的密鑰都用于測試嗎？好吧，告訴你一個可怕的消息：研究人員估計，所有發現的密文中89.10%是敏感信息。
• 幾個趨勢：密文減少最明顯的時候是在發現后的第一個小時，所有發現的密文中6%被移除。存在時間超過一天的密文往往長期存在——第一天結束時，12%以上的密文消失了，而16天后，只有19%的密文消失了。密文和文件被刪除的速度大大超過代碼庫被刪除的速度：用戶沒有刪除代碼庫，而是創建新的提交以刪除文件或密文。
• 最后，最重要的結論是：發現GitHub上分享的密文的平均時間為20秒左右，從半秒到4分鐘不等，密文在一天中的什么時間被推送沒有任何影響。所以在你不小心推送之后，留給你彌補的時間，比想象的要少得多。

三、結語

GitHub應該對可能暴露密文的提交，實行嚴格得多的政策或檢查。或者至少將新注冊的帳戶引到相應的說明文檔發出警告。筆者認為這對于剛開始踏上編程之旅的新人來說尤為重要。開發人員（尤其是新手）應該知道如何安全地公開源代碼，以及忽視這么做可能面臨的后果。

如何才能避免意外提交？這里給出幾點建議：

• 避免使用像git add.或git commit-a這樣的catch-all命令，而是使用git add filename。單獨暫存文件也可以更好地跟蹤提交方面的更改。你總是可以在流行的文本/源代碼編輯器（比如Visual Studio Code）的源代碼控制組件中使用暫存選項。
• 始終查看你的文件更改。使用git diff--cached，密切關注工作樹上的變化。
• 還有其他類型的工具可以幫助你避免提交像git-secrets這樣的密鑰。
• 你還可以使用預提交鉤子。

原文鏈接：http://www.codingwoman.com/git-the-good-the-bad-and-the-ugly/