Git “File Exceeds GitHub’s 100MB Limit”: How to Remove It

GitHub rejects a push when a Git object contains a file larger than 100 MiB. Removing the file only from your current folder is not enough if it is still stored in a commit. This guide helps you identify where it was added, remove it from the relevant history without deleting your local copy, or use Git LFS if you need to keep versioning the file.

Why GitHub rejects the push

GitHub blocks individual files larger than 100 MiB (where MiB means 1,024 × 1,024 bytes). The rejected file may have been added in your latest commit or an earlier, unpushed commit. A message such as GH001: Large files detected usually includes the file path and blob identifier.

Git stores committed file content in history. Deleting the file in a later commit does not erase the earlier version, so GitHub can still reject the push. First decide whether the file belongs in the repository at all. For assets that need version control, use Git Large File Storage (LFS).

Find the large file and check your Git status

Use the path shown in GitHub’s error if it is available. Before changing history, confirm your current branch and working tree, and save a backup of any work you cannot afford to lose:

git status
git log --oneline -- path/to/large-file

Replace path/to/large-file with the actual repository path. The log helps show whether the path appears in a recent commit. Do not copy a blob ID from the error and assume it is a filename; use the reported path when removing a file by path.

Remove a file from the latest commit but keep it on your computer

If the large file was added only in your most recent commit and that commit has not been pushed, remove it from Git’s index while preserving the working copy:

git rm --cached -- path/to/large-file
echo "path/to/large-file" >> .gitignore
git add .gitignore
git commit --amend --no-edit

git rm --cached removes the tracked file from the upcoming snapshot but leaves the file on disk. The ignore rule prevents accidentally adding it again. Amend replaces the latest commit with a corrected version; check that the latest commit is yours and has not been shared before amending.

Verify before retrying the push:

git status
git ls-files -- path/to/large-file
git show --stat --oneline HEAD

Remove a file from an earlier unpushed commit

If the file exists in multiple commits, amending only the latest commit will not remove older copies. For an unpushed branch, use git-filter-repo to remove that path from the branch’s history. Make a separate backup first; this rewrites commits:

git filter-repo --path path/to/large-file --invert-paths

Run the command from a repository where git-filter-repo is installed, using the exact path relative to the repository root. If the file was committed under different names or paths, include every path that must be removed. This command removes those paths from all rewritten history, not just the current snapshot.

Rewriting history changes commit IDs. If the branch is already shared, coordinate with collaborators and review the remote state before updating it. Do not force-push a shared branch blindly; doing so can overwrite other people’s work.

Keep the large file with Git LFS

If the file is a model, archive, video, or another asset that must be versioned, Git LFS stores its contents outside ordinary Git objects. Installing LFS and tracking the file affects future adds; if the oversized blob is already in commits, migrate the existing history as well.

git lfs install
git lfs track "path/to/large-file"
git add .gitattributes
git add path/to/large-file

For an existing unpushed branch, use the Git LFS migration workflow to convert the old commits too; simply tracking the path now does not remove the original large blob from earlier commits. Check your Git host’s LFS storage and bandwidth limits before migrating.

Common questions

Does deleting the file fix the GitHub error?

Not if a commit being pushed still contains it. Remove it from the relevant commit history, or migrate that history to Git LFS.

Will git rm --cached delete my local file?

No. The --cached option removes the file from Git’s index and keeps the working copy. Review git status before committing.

Can I add it to Git LFS after the push fails?

Yes, but tracking alone only handles later versions. Migrate or rewrite commits that already contain the regular Git blob before pushing again.