目前我有
SSH服务器repo是最新的repo（生产站点）所以我从那里做了一个Git克隆到本地。然后我尝试对GitHub进行git push。
一切都很好但是后来它说了一些关于filename.gz对于GitHub来说太大了。我不需要这个文件所以我运行了几个Git命令来从Git缓存中删除它然后推回到SSH服务器。
我没有在本地看到大文件，但它仍然在SSH服务器上，即使git diff没有返回任何内容而git push返回“Everything is latest-date” - 尽管文件在当我尝试推送到GitHub的本地回购我仍然得到关于它的错误
remote：错误：文件fpss.tar.gz是135.17 MB;这超出了GitHub的文件大小限制100 MB
我按照“解决问题”listed on GitHub help下的步骤进行操作，那么这应该不够吗？
当文件不在本地或在git status / diff / push中列出时，文件如何仍然在以太网中？
答案 0 :(得分：359)
您可以使用
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD
这将删除该文件历史记录中的所有内容。问题是文件存在于历史记录中。
此命令更改提交的哈希值，这可能是一个真正的问题，尤其是在共享存储库上。如果不了解后果，就不应该这样做。
答案 1 :(得分：34)
如果文件添加了您最近的提交，并且您没有推送到GitHub ，则可以删除该文件并修改提交，取自{{ 3}}：
git rm --cached giant_file
# Stage our giant file for removal, but leave it on disk
git commit --amend -CHEAD
# Amend the previous commit with your change
# Simply making a new commit won't work, as you need
# to remove the file from the unpushed history as well
git push
# Push our rewritten, smaller commit
答案 2 :(得分：22)
我发现squashing比filter-branch更有用。我做了以下事情：
git reset
--soft HEAD~3。 git commit -m
"New message for the combined commit" 特殊情况 （来自用户@lituo）：如果上述情况不起作用，那么您可能会遇到此情况。提交1包含大文件，并且由于大文件错误，提交1的推送失败。提交2按git rm --cached [file_name]删除了大文件，但提交2的推送仍然失败。您可以按照上述相同步骤操作，但不要使用HEAD~3，而是使用HEAD~2。
答案 3 :(得分：13)
我遇到了类似的问题，并使用step above删除了该文件。它工作得很好。
然后我在需要删除的第二个文件上出错：
remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub's file size limit of 100.00 MB
我尝试了同样的步骤，得到了一个错误："A previous backup already exists in <path/filename>"
通过对this website的研究，我使用了命令：git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --prune-empty --tag-name-filter cat -- --all
工作得很好，并删除了大文件。
令人难以置信的是，推送仍然失败并出现另一个错误：error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly
我通过直接修改.git配置文件 - postBuffer = 999999999
之后推进了！
答案 4 :(得分：9)
Git会存储您项目的完整历史记录，因此即使您删除了＆＃39;来自你的项目的文件，Git repo仍然有一份文件的副本历史，如果你试图推送到另一个存储库（比如在GitHub上托管的那个），那么Git 需要远程仓库与您的本地仓库具有相同的历史记录（即其历史记录中的相同大文件）。
您需要在本地清理项目的Git历史记录，从所有历史记录中删除不需要的大文件，然后仅使用“已清理的”文件。历史未来。受影响提交的Git提交ID将发生变化。
用于清除Git历史记录中不需要的大文件的最佳工具是BFG Repo-Cleaner - 它是git-filter-branch的一种更简单，更快速的替代方案，专门用于从Git历史记录中删除不需要的文件。
仔细遵循usage instructions，核心部分就是这样：
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git
任何超过100MB的文件（不在最新提交中）都将从您的Git存储库历史记录中删除。然后，您可以使用git gc清除死数据：
$ git gc --prune=now --aggressive
BFG通常比运行git-filter-branch至少10-50x快，并且通常更容易使用。
完全披露：我是BFG Repo-Cleaner的作者。
答案 5 :(得分：7)
我已经尝试了上述所有方法，但是对我来说都不起作用。
然后我想出了自己的解决方案。
首先，您需要一个干净的最新本地存储库。删除所有该死的大文件。
现在在您的repo文件夹之外创建一个新文件夹，并使用“此处的Git创建存储库”将其设为新的Git存储库，我们将其称为new_local_repo。 就是这样！以上所有方法都说您必须清除历史记录...，嗯，我对此感到厌烦，让我们创建一个完全没有历史记录的新回购！
将文件从旧的，搞砸了的本地存储库复制到新的，漂亮的存储库。请注意，文件夹图标上的绿色徽标将消失，这很有希望，因为这是一个新的仓库！
提交到本地分支，然后推送到远程新分支。我们称其为new_remote_branch。如果您不知道如何从新的本地存储库中推送，请使用Google。
恭喜！您已将干净的最新代码推送到GitHub。如果不再需要远程master分支，则可以将new_remote_branch设置为新的master分支。如果您不知道如何操作，请使用Google。
最后一步，是时候删除该死的旧本地存储库了。将来，您只会使用new_local_repo。
答案 6 :(得分：7)
如果您在寻求帮助之前一直在搞弄仓库，那么我发现这对您很有帮助。第一种：
git status
此后，您应该会看到
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
重要的部分是“ 2次提交”！从这里继续输入：
git reset HEAD~<HOWEVER MANY COMMITS YOU WERE BEHIND>
因此，对于上面的示例，将键入：
git reset HEAD~2
键入后，您的“ git状态”应显示为：
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
您可以从那里删除大文件（假设您尚未删除大文件），并且应该能够重新提交所有内容而不会丢失工作。
我知道这不是花哨的答复，但我希望它能有所帮助！
答案 7 :(得分：2)
我遇到了同样的问题，没有一个答案适合我。我通过以下步骤解决了：
git log --all -- 'large_file`
底部提交是结果列表中的最早提交。
git log
假设你得到了：
commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
提示：
drop提交包含大文件。git rebase --continue继续，直到您完成它。git rebase --abort取消它。 答案 8 :(得分：2)
git lfs migrate import --include="fpss.tar.gz"
这应该使用新的lfs refs重写您的本地提交
答案 9 :(得分：2)
将大文件/文件夹保留在工作文件夹中的解决方案
这是解决这里所问问题的行（答案1）：
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD
如果该文件/目录在工作树中，则此命令还会删除该文件/目录。
如果要将文件/文件夹保留在工作树中，我建议采取以下步骤。
git reset HEAD^ 将有问题的文件/文件夹添加到.gitignore`文件中。
照常执行git add .，该操作可能会捕获其他文件/文件夹，但必须捕获.gitignore文件。接下来是git commit -m"message"，最后是git push origin <branch_name>
答案 10 :(得分：2)
使本地存储库与远程存储库匹配：
git reset --hard origin/master
然后再次推送。
答案 11 :(得分：0)
这对我有用。来自github的文档 壁球提交 git reset origin / master
git checkout master && git pull;
git merge feature_branch;
git add . --all;
git commit -m "your commit message"
查找文档here
答案 12 :(得分：0)
所以我遇到了一种特殊情况：我从gitlab克隆了一个存储库，该存储库包含一个大于100 mb的文件，但是在git历史记录中的某个时候被删除了。然后稍后，当我添加一个新的github私有仓库并尝试推送到新仓库时，我得到了臭名昭著的“文件太大”错误。至此，我不再可以访问原始的gitlab存储库。但是，我仍然可以使用bfg-repo-cleaner推送到我机器上的本地存储库中的新私有github存储库：
$ cd ~
$ curl https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar > bfg.jar
$ cd my-project
$ git gc
$ cd ../
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-project
$ cd my-project
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
$ git remote -v # confirm origin is the remote you want to push to
$ git push origin master
答案 13 :(得分：0)
有时文件会保留在跟踪历史记录中，请尝试以下步骤：
git commit，如果您看到带有列出的大文件的创建模式，请执行以下操作： git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch filename' HEAD。
您应该会在控制台中看到一堆重写，其结尾为：
rm'文件名'和
最后一行 Ref 被重写。
完成了。
答案 14 :(得分：0)
我的非传统但简单的解决方案：
git clone放到新的目录中即可。git remote add upstream <your github rep here> git pull upstream master git add . git commit -m "your commit text here" git push origin master 瞧！在我的情况下就像魅力一样。
答案 15 :(得分：0)
当我的iOS项目中没有gitignore文件时，我遇到了这个问题
我认为也许是试图将庞大的文件推送到github，而github可能拒绝了那个或多个巨型文件。
答案 16 :(得分：-1)
我要添加第一个答案。
git filter-branch --index-filter'git rm -r --cached --ignore-unmatch'HEAD
原始人/母公司会发生一些合并冲突。
您的分支机构和“来源/主管”已经分开， 并且分别具有114和109个不同的提交。 （使用“ git pull”将远程分支合并到您的分支中）
请运行
git reset --hard origin / master
它将丢弃我所有已上演和未上演的更改，忘记我当前的本地分支上的所有内容，并使它与原点/原版完全相同。
答案 17 :(得分：-1)
与其做复杂的事情，不如将您的存储库（在计算机上）复制到另一个地方。删除大文件。做几次推拉。然后，您的某些文件将被搞乱，例如“ <<<<<<< HEAD”。只需将备份复制到磁盘上的旧文件夹中即可。再做一次添加，提交，推送！
答案 18 :(得分：-1)
如果您要上传自己的项目，则只需转到存在目录的文件即可。 删除大文件。 然后单击“视图”（窗口文件） 查看->检查隐藏文件夹 然后您将能够看到“.git”文件 删除 .git 文件 这将删除您所有的提交历史记录 然后你可以像新的一样推送你的仓库......