由于我已经删除的大文件，无法推送到 GitHub

您可以使用

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD

这将删除该文件历史记录中的所有内容。问题是该文件存在于历史记录中。

此命令会更改提交的哈希值，这可能是一个真正的问题，尤其是在共享存储库上。在不了解后果的情况下不应执行此操作。

---

我发现 squashing 比 filter-branch 更有用。我做了以下事情：

本地删除大文件。提交本地删除。软重置 X 次提交（对我来说是 3 次）：git reset --soft HEAD~3。然后一起重新提交所有更改（AKA squash） git commit -m "New message for the combined commit" Push squashed commit。

特殊情况（来自用户@lituo）：如果以上不起作用，那么您可能有这种情况。 Commit 1 包含大文件，由于大文件错误，Commit 1 的推送失败。提交 2 通过 git rm --cached [file_name] 删除了大文件，但提交 2 的推送仍然失败。您可以按照上述相同的步骤操作，但不要使用 HEAD~3，而是使用 HEAD~2。

---

如果您在寻求帮助之前已经在搞乱您的存储库，那么我发现这是非常有用的东西。第一种：

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 status”应该说：

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

从那里，您可以删除大文件（假设您还没有这样做），并且您应该能够重新提交所有内容而不会丢失您的工作。我知道这不是一个超级花哨的回复，但我希望它有所帮助！

---

如果文件与您最近的提交一起添加，并且您尚未推送到远程存储库，您可以删除该文件并修改提交，取自 here ：

git rm --cached giant_file
    # Stage "giant_file" for removal with "git rm"
    # Leave it on disk with "--cached". if you want to remove it from disk
    # then ignore the "--cached" parameter
git commit --amend -CHEAD
    # Commit the current tree without the giant file using "git commit"
    # Amend the previous commit with your change "--amend" 
    # (simply making a new commit won't work, as you need
    # to remove the file from the unpushed history as well)
    # Use the log/authorship/timestamp of the last commit (the one we are
    # amending) with "-CHEAD", equivalent to --reuse-message=HEAD
git push
    # Push our rewritten, smaller commit with "git push"

---

为什么 GitHub 拒绝我的仓库，即使我删除了大文件？

Git 会存储您项目的完整历史记录，因此即使您从项目中“删除”一个文件，Git 存储库仍会在其历史记录中保存该文件的副本，并且如果您尝试推送到另一个存储库（例如托管在GitHub）然后 Git 要求远程仓库与您的本地仓库具有相同的历史记录（即其历史记录中的相同大文件）。

我怎样才能让 GitHub 接受我的回购？

您需要在本地清理项目的 Git 历史记录，从所有历史记录中删除不需要的大文件，然后仅使用“清理过的”历史记录。受影响提交的 Git 提交 ID 将更改。

如何从我的 Git 存储库中清除大文件？

从 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 的作者。

---

我遇到了类似的问题并使用 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

之后推就通过了！

---

我已经尝试了上述所有方法，但它们都不适合我。

然后我想出了自己的解决方案。

首先，您需要一个干净、最新的本地存储库。删除所有大文件。现在在您的 repo 文件夹之外创建一个新文件夹，并使用“Git create repository here”将其设为新的 Git 存储库，我们将其命名为 new_local_repo。就是这个！以上所有方法都说你必须清理历史......，好吧，我厌倦了，让我们创建一个根本没有历史的新仓库！将文件从旧的、混乱的本地 repo 复制到新的、漂亮的 repo。请注意，文件夹图标上的绿色标志会消失，这是有希望的，因为这是一个新的 repo！提交到本地分支，然后推送到远程新分支。我们称它为 new_remote_branch。如果你不知道如何从一个新的本地仓库推送，谷歌一下。恭喜！您已将干净、最新的代码推送到 GitHub。如果您不再需要远程 master 分支，您可以将 new_remote_branch 设置为新的 master 分支。如果你不知道怎么做，谷歌它。最后一步，是时候删除混乱的旧本地仓库了。将来您只使用 new_local_repo。

---

我遇到了同样的问题，没有一个答案对我有用。我通过以下步骤解决了：

1. 查找哪些提交包含大文件

git log --all -- 'large_file`

底部提交是结果列表中最旧的提交。

2. 找到最老之前的那个。

git log

假设你得到：

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. Git 变基

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

提示：

我刚刚为提交选择 drop 的列表项包含大文件。你可能会在 rebase 修复它们时遇到冲突，并使用 git rebase --continue 继续直到你完成它。如果在 rebase 期间出现任何问题，请使用 git rebase --abort 取消它。

---

git lfs migrate import --include="fpss.tar.gz"

这应该用新的 lfs refs 重写你的本地提交

https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn?utm_source=gitlfs_site&utm_medium=doc_man_migrate_link&utm_campaign=gitlfs#examples

---

将大文件/文件夹保留在工作文件夹中的解决方案

这是解决此处提出的问题的行（来自答案 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

---

不知何故，这对我有用。我尝试了所有解决方案，但这个命令节省了我的时间。希望这对你也有帮助。

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <file/folder path>' --prune-empty --tag-name-filter cat -- --all

请自行承担风险。我不会为你的行为负责。

从根目录运行此命令

---

我从头开始的非正统但简单的解决方案：

忘记你最近有问题的本地 git 存储库，然后 git clone 你的存储库到一个新的目录。

git remote add upstream <你的 github 代表在这里>

git pull 上游大师

此时只需将您的新文件复制到提交，从旧的本地代表到您的新本地代表可能包括您现在减少的巨型文件。

混帐添加。

git commit -m "你的提交文本在这里"

git push 起源大师

瞧！在我的情况下就像一个魅力。

---

如果您要上传自己的项目，那么只需转到目录所在的文件即可。删除大文件。然后点击“查看”（窗口文件）查看->检查隐藏文件夹然后你将能够看到'.git'文件删除.git文件这将删除你所有的提交历史然后你可以像新的一样推送你的repo。 ..

---

这对我有用。来自 github 的文档 Squashing Git Commits git reset origin/master

git checkout master && git pull;
git merge feature_branch;
git add . --all;
git commit -m "your commit message"

查找文档 here

---

所以我遇到了一个特殊的情况：我从 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

---

有时文件会保留在跟踪历史记录中，请尝试以下步骤：

git commit，如果您看到列出了大文件的创建模式，那么执行： git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch filename' HEAD。您应该会在控制台中看到一堆 Rewrites，它们以 rm 'filename' 结尾，最后一行 Ref 被重写。

完成。

---

而不是做复杂的事情，将您的回购（在您的计算机上）复制到另一个地方。删除大文件。做几个推拉。然后你的一些文件会被“<<<<<< HEAD”之类的东西弄乱。只需将备份复制到磁盘上的旧文件夹中即可。再做一次添加、提交、推送！

---

当我的 iOS 项目没有 gitignore 文件时，我遇到了这个问题

我想也许它试图将一个巨大的文件推送到 github，而 github 可能拒绝了那个巨大的文件或（文件）

---

什么对我有用：

将我的 GitHub 项目文件夹重命名为其他内容 使用正确的文件夹名称重新克隆 repo 删除重命名的 repo 中的 .git 文件夹（可能必须打开允许查看 Windows 中的隐藏文件） 从正确的文件夹中移动 .git 文件夹重命名的名称删除重新克隆的 repo 文件夹，将原始 repo 文件夹重命名为正确的名称提交您的更改（没有大文件）并推送

---

我之所以这样做，是因为您的已删除文件可能已经存在于您的提交中，以检查首次使用

git log

这将返回您在当前分支中的提交列表，找到您要查找的确切提交的 id，

然后使用，

git show <commit_id>

这应该显示提交的详细信息以及其中包含的文件

现在要解决您的问题，请使用

git reset --soft HEAD~1

这里 HEAD~1 上的 1 代表之前的提交，你可以根据你需要的提交使用不同的数字，如果你需要倒数第二个提交就使用， git reset --soft HEAD~2

这会将您的 Head 重置为先前的提交，如果此提交没有大文件，那么您可以这样做，

git add .

git commit -m <message_for_commit>

git push origin <repo_name>

别的

如果您想重置为不包含您的文件的特定提交，只需使用

git reset --soft <commit_id>

然后从这里创建一个没有删除文件的新提交并推送它

---

我正在添加第一个答案。

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch' HEAD

来自源/主将存在一些合并冲突。

你的分支和 'origin/master' 已经分道扬镳，分别有 114 和 109 个不同的提交。 （使用“git pull”将远程分支合并到你的）

请运行这个

git reset --hard origin/master

它将丢弃我所有分阶段和非分阶段的更改，忘记我当前本地分支上的所有内容，并使其与 origin/master 完全相同。

---

使您的本地存储库与远程存储库匹配（所有本地更改都将丢失）：

git reset --hard origin/master

然后再推。

---