無法從git存儲庫中刪除文件？

Question

我已經添加文件> 100 Mb到我的git倉庫，它在本地git中工作。不幸的是，github有100 MB的限制。

因此，我重寫了代碼，以便它不需要這個大文件，然後刪除它，然後提交。

不幸的是，我仍然無法推送到gothub，因爲文件仍在存儲庫中。

我試圖運行

git rm --cached my_file.dat 

git rm --cached -r my_file.dat 

git rm --cached mypath/my_file.dat 

和所有命令與

fatal: pathspec ... did not match any files 

失敗如何刪除文件W/O指定給它確切的路徑？

UPDATE

我試圖運行

java -jar bfg.jar --strip-blobs-bigger-than 100M 

，並將其與消息未能

Scanning packfile for large blobs completed in 2 ms. 
Warning : no large blobs matching criteria found in packfiles - does the repo need to be packed? 

但仍無法

git push origin master 

與

File my_path/my_file.dat is 257.62 MB; this exceeds GitHub's file size limit of 100.00 MB 

Answer 1

您需要以某種方式從所有提交中刪除此文件。

幾種方法可以做到這一點是：

• ，如果你有一個相當低的數目提交的編輯：
  使用git rebase -i手動編輯提交
• ，如果你有做大規模（許多提交，幾個分支）： 使用git filter-branch --index-filter
  或@Sirko

建議

如何使用git變基-i：

如果你的歷史是這樣的：

 big file added here 
     v 
--*--A--B--C--D--E--F <- master 

返工B的內容，則需要從其父變基：

git rebase -i A 

這將打開一個文本編輯器，它會詢問您要對從B到F的每次提交執行什麼操作

它將開始：

pick B message 
pick C message 
pick D message 
... 

你想改變B，除去從這個大的文件提交

# set the action on b to 'edit' (or e) : 
e B message 
pick C message 
pick D message 
... 

保存並關閉。

現在git會運用你告訴他的行動：

• 他會倒帶你的回購高達A
• 你告訴git的編輯B：他將適用B，然後停止，以便您可以做任何你想做

• 刪除從此大文件提交：

  git rm --cached big/file 
  git commit --amend 
  

• 現在你要告訴git的恢復與重訂基期：

  git rebase --continue 
  

• 你應該看到說明git的消息是重播C，那麼d ..達到F

Answer 2

的文件仍然是在倉庫的歷史...您需要刪除提交（S）介紹了吧...

如果你能清晰地識別提交介紹了它，那麼請嘗試以下操作：

git rebase -i ${COMMIT_ID}^ 

這將顯示提交列表，您可以選擇edit或drop某些項目。通過將缺省的pick替換爲drop來簡單地刪除它（和所有其他更改，即提交所做的更改！），或者使用edit標記違規提交，刪除文件，重新提交併確認，標記違規提交。

完成此操作後，請再試一次。

---

Git是不是真的專爲大型二進制文件，這樣避免了檢查它們。 如果「需要」來，那麼它可能是值得一試的Git Large File Storage項目。

Answer 3

順便說一句，刪除文件完全是最簡單的選擇（雖然你看，這不完全是簡單的），前提是你不需要的文件在您的回購協議。另一個選擇是使用像git lfs這樣的工具來允許你的倉庫引用文件，而不需要直接將文件放入你的倉庫。這解決了與git中的大文件相關的許多問題，如果您確實需要該文件，應該考慮這些問題;但重寫回購使用lfs爲一個已經提交的文件是另一個完整的話題...

所以，回到刪除的問題。爲了提供多一點背景：

Git中有三個地方的文件會被發現。

1）工作樹木 - 僅僅是純文本文件，你努力。 git沒有特別的努力來保存這裏的數據，它只存在於本地。您可以通過git以外的方式或使用git rm（特別是如果您還需要將其從索引中刪除）從這裏刪除文件。

2）索引 - 這是「分階段」進行新提交的文件。當你說git add你更新索引。 git將掛在這裏獨立於工作副本的數據，但仍然只是本地的，並沒有特別的努力來保存歷史。 git rm將從索引中提取文件。

3）數據庫 - 這是你的項目的歷史存在。當你說git commit時，將表示項目的「對象」添加到數據庫中。該數據庫是git保留歷史，你必須走出去的方式，使git從這裏丟失任何數據。數據庫基本上是在push和fetch操作期間在回購期間共享的內容。 git rm對數據庫沒有影響。

現在，正如其他人所指出的，因爲你已經創建了一個提交包含文件，你需要做的比git rm多。第一步是重寫任何包含提交文件的提交文件的歷史記錄。

有人說你需要解決的承諾是「介紹」的文件;這是誤導。您需要處理全部對該文件的引用（或者在技術上，對代表該文件的BLOB對象）。

因爲rebase解釋，相對於他們的父母他們的變化方面承諾，它可以在一個相對便捷的方式處理這個問題，如果有的不是很多分支與合併加入的文件後發生的情況。例如，如果文件是在提交A中創建的，並且唯一可以訪問A的引用是master，並且在master中沒有合併提交比A更新，那麼rebase是最簡單的解決方案。假設A不是根提交，

git rebase -i A^ master 

（其中A^是的SHA提交所引入的文件）;但如果A是根提交，這意味着A^是無效的，那麼

git rebase -i --root master 

在彈出待辦列表，您更改A編輯命令，給出的提示進行編輯時提交你刪除文件，然後告訴rebase繼續。

在這一點上，可能git push將工作，因爲git不必發送整個數據庫;它只是發送你告訴它推的參考文獻的歷史。但不要混淆：你仍然尚未從本地數據庫中刪除文件。要做到這一點，你必須確保沒有任何東西（即使是reflog）可以到達該文件，然後使用git gc。如果您已成功從所有裁判的歷史記錄中刪除該文件，則最終會發生這種情況;這可能是文件，除非你受限於本地存儲。

在上述過程中有幾個重要的假設，如果您剛剛提交了這些假設可能存在的文件。但是如果存在多個分支可以達到承諾A，並且/或者如果有合併提交可以達到A，那麼執行rebase會變得更加困難。那時你會看到git filter-branch或BFG Repo Cleaner作爲解決方案。在這兩項中，BFG對於這項任務來說要簡單得多，速度更快;如果你搜索它，你可以找到許多來源（包括一些SO條目），概述了它的用法。因爲filter-branch更通用，所以使用起來更加困難，但它又是「內置」的 - 無需下載其他軟件。

所有這些技術都會重寫歷史記錄。由於您無法推送現有的歷史記錄，因此這可能不是什麼大問題（假設您沒有第二個已經推送更改的遙控器）。