我們的開源專案放在 GitHub 上的倉庫由於收到了 DMCA Takedown 投訴被封禁，倉庫處於不可訪問狀態。在解決了這個驚魂事件之後，我們將此中得到的教訓和經驗分享給大家。-- Bestony
有用的原文連結請訪問文末的“原文連結”獲得可點選的文內連結、全尺寸原圖和相關文章。致謝　作者　|　Bestony

倉庫被封禁

在 2018 年 2 月 20 日，我們的開源專案放在 GitHub 上的倉庫由於收到了 DMCA Takedown 投訴被封禁，倉庫處於不可訪問狀態。此時在 GitHub 上訪問該倉庫時，會顯示一個公開訊息，表明該倉庫被封禁的原因。

按照 GitHub DMCA 的規則，GitHub 在確認投訴有效後，會給該倉庫的管理員傳送一封郵件，提示該倉庫需要在 24 小時內清理被投訴的內容，並回覆

 GitHub 才行——否則，該倉庫會被封禁，禁止任何訪問和資料匯出。

我們在收到該 Takedown 投訴後，會有 24 小時的時間來響應，但由於過年期間，倉庫擁有者沒有及時看到郵件，未能及時發現這麼嚴重的通知。因此，在過了 24 小時後， Github 按照 DMCA 的規則，進行了倉庫的封禁。

倉庫被封禁後，我們發現無法訪問。根據封禁訊息的提示，發現原來之前倉庫內的某個檔案出了問題，侵犯了原作者的版權。原作者向 Github 傳送了 DMCA 投訴。而由於我們的未及時處理，導致了倉庫的最終被封。當我們發現被封時，已經是深夜了。

緊急商討方案

在被封禁後，由於已經超過了 24 小時時限，在這個階段下， GitHub 的文件中給出的解決方案僅有請求 GitHub 來刪除該倉庫並根據自己手裡的倉庫資料重建的方案。但對我們來說，這種方案是不可接受的，因為這種方案會導致丟失所有的 issue、PR、Wiki，以及你本地的倉庫和遠端的倉庫之間的版本差異。

我們在群內先找了更新最全的 fork，找到了一個群友提供的，和上游只差 2 個提交的版本，並將其儲存下來，作為最後的自救手段。

此外，在查詢 DMCA 的過程中，我瞭解到 DMCA 除了有 DMCA Takedown 以外，還有一個 DMCA Counter Notice，用於反向解除 DMCA 封禁。

DMCA Counter Notice

DMCA Counter Notice 用於向服務商發起申訴，說明 DMCA Takedown 投訴為惡意投訴且並無版權問題。

延展閱讀

https://www.plagiarismtoday.com/2010/06/03/7-common-questions-about-dmca-counter-notices/

https://help.github.com/articles/guide-to-submitting-a-dmca-counter-notice/

當時考慮到我們已經錯過了視窗期，沒辦法刪除 GitHub 上倉庫中的特定檔案，所以想通過 DMCA Counter Notice 來解除封禁。

為此，我通過 Github 發給我們的郵件，找到了那份侵權檔案，並在他的網站中找到了版權擁有者的郵件，傳送郵件說明情況，看看能否通過付費獲得授權。但其是挪威人，存在時差，所以我們只能邊等待，邊想辦法。

山重水複疑無路，柳暗花明又一村

在準備 DMCA Counter Notice 時，我們又向 Github 傳送了郵件，說明了中國春節的特殊情況，導致我們沒有來得及處理檔案，請求給我們一個機會讓我們處理這些檔案。但是遲遲沒有迴應，無奈之下，多位成員又以成員身份向 GitHub 傳送郵件，請求給予幫助。

令人驚奇的是，經過大約 9 個小時的等待，倉庫擁有者的請求郵件似乎開小差了，而各位成員的請求郵件得到了響應。Github 回信給大家說，根據其規則，給出了額外的 24 小時視窗期，讓我們處理這些檔案（後來經過仔細查閱 GitHub 的 DMCA Takedown 規則，對這種錯過了第一次視窗期的情況，可以給予第二個，也是最後一個視窗期）。但是這個開啟額外的視窗期，需要倉庫的擁有者向 GitHub 傳送郵件請求。

然後，我們就以倉庫擁有者的身份再次向 GitHub 傳送了請求，可能是由於時差的原因，又是幾個小時沒有迴應。

與此同時，我們也收到了版權擁有者的回覆。很遺憾，原作者不願意授權，也不打算收費。好在 Github 給的額外視窗期，讓我們有了改正錯誤的機會。

還好，在焦急的等待之中，我們終於收到了 GitHub 的回覆，並同時恢復了倉庫的訪問——寶貴的 24 小時視窗期。

使用 BFG 處理檔案

得到了視窗期後，我們開始處理倉庫內的檔案。

首先，你得清除了現在還在倉庫裡面的檔案，然後再使用下面的方面來清除提交歷史中的資料。

推薦閱讀

以下文章建議按順序閱讀

https://help.github.com/articles/removing-sensitive-data-from-a-repository/

https://rtyley.github.io/bfg-repo-cleaner/

刪除 Git 倉庫的歷史資料有多種方法，一種是使用 git filter-branch來處理，但是速度極慢。另外一種就是使用 BFG 來處理，我們採用的是 BFG 來處理（BFG 是git filter-branch 首字母的逆轉）。

BFG 需要 Java 的執行環境，如果無法執行，請檢查你的本地 Java 環境是否安裝，或高於 Java 7 。

Java 6 需要使用 bfg v1.12.3版本

BFG 的處理過程比較簡單，首先，你需要下載 BFG。

1. wget http://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar

然後克隆你的倉庫到本地，比如 bestony/test。

1. gitclone--mirror  git://github.com/bestony/test.git

克隆時用不用 --mirror 模式都可以，但是後續命令上會有所差距，所以我還是推薦大家使用映象模式，畢竟按照官方的文件走，出現了問題也好搜尋。（映象模式克隆的倉庫和遠端倉庫完全一樣，但是不能直接看到倉庫裡面的檔案，而且也不能允許 git 的各種命令）

克隆到本地後，執行 BFG 命令來處理檔案。

1. cdtest.git

2. java -jar bfg.jar --delete-files "filename"

這裡需要注意的是，filename 不支援目錄路徑，只能是檔名，而不能是 dir/filename 這樣的形式，所以新增引數時你要注意這個。對於有同樣名字的檔案卻想只刪除某個目錄的情況，可能就沒有辦法了。

此外，預設情況下， BFG 不會處理最新的提交，它認為你的最新提交應該是乾淨的（不包含需要刪除的敏感資料），如果你要刪除的檔案是最新的提交（比如你最新的一個提交是刪除那些敏感資料），可以加入--no-blob-protection引數來強制清除，也可以再新增一個提交，使包含了要被刪除檔案的提交不是最新的提交。

1. java -jar bfg.jar --delete-files "filename"--no-blob-protection

BFG 處理完成後，會提示你使用 git 命令進行垃圾回收，你需要執行如下命令來操作：

1. cdtest.git#進入目標目錄

2. git reflog expire --expire=now --all &&git gc --prune=now --aggressive #垃圾回收

這裡需要注意的是，如果你刪除多個檔案，每次刪除後執行和多個檔案都刪除後效果一樣，所以建議你刪除多個檔案後再進行垃圾回收，會更省時一些。

處理完成後，將資料推送到遠端即可（需要關閉 GitHub 上倉庫設定裡面對強制推送的防護）：

1. git push

執行完成後，就可以到遠端上去看了，你的檔案會被刪除，相關的提交不會被刪除，但是提交裡面不包含該檔案了。

在推送時，可能會提示你有些更改被拒絕了，這些更改如果是和 Pull Request 有關的，你可以不需要在意，這是 GitHub 自身的問題。Github 設定 Pull Request 是隻讀不可改的。所以我們無法修改這些資訊。

具體可以參考 https://github.com/rtyley/bfg-repo-cleaner/issues/36

至此，我們將檔案進行了刪除處理，並清除了相關的資料。

後續處理

在完成檔案及歷史資料的刪除後，我們將我們的刪除結果回覆了 Github ，等待 Github 的確認。GitHub 會在 24 小時收到該回復後，會通知投訴方進行確認。如果投訴方無異議，此事就此結束，不會再有下一步動作。如果有異議，則會重新進行此流程。

此外，由於 GitHub 存在垃圾快取回收的時間差，所以你推送到 GitHub 上的資料雖然並無需要被刪除的檔案，但是依舊在一定時間內可以看到。這種快取只能請 GitHub 自行操作刪除。此外，與要刪除的檔案相關的 Pull Request 也需要 GitHub 來刪除——因為使用者是沒有許可權刪除 Pull Request 的。這些請求也可以一併發給 GitHub 來操作（但似乎 GitHub 並不熱衷執行這些請求，只要被投訴的檔案訪問不到即可，也就是說，如果沒有被投訴歷史資料，其實或許並不用大動干戈清理歷史……）。

這種清除操作還有一個副作用就是，所有之前 fork 的倉庫，由於主倉庫被封禁而導致各個 fork 倉庫的 remote 意外地變為另外一個倉庫（該倉庫是最早的一個 fork 倉庫）。而主倉庫恢復之後，我們並沒有找到好的辦法將 remote 恢復回原來的主倉庫。因此，需要所有成員重新 fork 主倉庫並從緩慢的 GitHub 克隆到本地。

餘思

這個驚魂事件當中，我們首先要反思的是，我們對版權問題的認識不足，這是一切問題的根源。因此，這之後，我們對既有資料進行了排查。

其次，GitHub 在這種事件的處置上，我們認為也並不夠好。這麼嚴重的處置（整個庫封禁），僅僅通過一份普通的郵件通知，而且僅僅給出 24 小時的時間視窗。而 GitHub 其實掌握了倉庫擁有者的更可靠、更及時的聯絡方式，比如說手機簡訊，也完全可以在 GitHub 的網頁介面上以顯目的方式提醒。另外，雖然 DMCA 規則中提到了可以容情第二個時間視窗，但是似乎這個附加視窗期是後來才改變的政策，在前面的流程說明中並未提及，很容易忽視。

其三，由於封禁會導致對該倉庫的所有訪問均不可進行，這不僅包括了提交資料，也包括了並沒有存在於 Git 倉庫中的 issue、PR 和 Wiki 等資料，而 GitHub 不會讓你在封禁的情況下有機會匯出這些資料。所以，有機會的話，各種資料還是有個備份的好。

最後，感謝在這個事件中，所有不離不棄支援我們的成員，感謝小白進行的倉庫清理工作。

相關閱讀

◈ https://blog.kongfanjian.com/2015/03/02/%E6%B0%B8%E4%B9%85%E5%88%A0%E9%99%A4git%E4%BB%93%E5%BA%93%E4%B8%AD%E7%9A%84%E6%96%87%E4%BB%B6%E4%B8%8E%E5%8E%86%E5%8F%B2%E8%AE%B0%E5%BD%95/◈ https://changkun.us/archives/2017/11/239/◈ http://debugtalk.com/post/clean-sensitive-data-from-git-history-commits/◈ http://www.voidcn.com/article/p-njmjnwov-bgk.html◈ http://www.vicviz.com/githubshang-de-min-gan-shu-ju-de-shan-chu/◈ https://lightless.me/archives/remove-sensitive-data-on-github.html◈ http://blog.csdn.net/duandianR/article/details/78843582◈ https://www.clock.co.uk/insight/deleting-a-git-commit◈ https://www.jacoballred.com/web-dev/use-bfg-to-completely-remove-a-file-from-your-git-repo/◈ https://community.atlassian.com/t5/Questions/BFG-for-a-Noob/qaq-p/350944◈ https://w3guy.com/remove-git-commit-history/