Introduction

When GitHub says a file exceeds the 100 MB file size limit, the immediate problem is not Git LFS itself. The problem is that the large binary was committed into normal Git history instead of being stored as a Git LFS object. GitHub rejects that push before it ever becomes a healthy LFS workflow.

The fix depends on timing. If the large file is only in your working tree, track it with Git LFS before committing. If the oversized blob is already in commit history, you need to rewrite that history so Git stores an LFS pointer instead of the raw file contents.

What Git LFS Actually Does

Git LFS replaces large files in Git history with small pointer files. The real file contents are stored in the LFS store, while the repository keeps lightweight references.

A typical setup looks like this:

1git lfs install
2git lfs track "*.psd"
3git add .gitattributes
4git add design/mockup.psd
5git commit -m "Track PSD files with Git LFS"

That works only if the large file is being committed after LFS tracking is in place.

If the Large File Is Already Committed

A common mistake is to add Git LFS after the oversized file is already part of history. GitHub will still reject the push because the old commit contains the full blob.

In that case, migrate the file into LFS history:

git lfs migrate import --include="path/to/bigfile.zip"

Or for a pattern:

git lfs migrate import --include="*.zip,*.mp4"

This rewrites commits so the large blobs become LFS pointers. After that, you usually need to force-push the rewritten history.

Verify That LFS Is Tracking the File

Before pushing, inspect the tracked patterns and the file state:

git lfs track
git lfs ls-files

If the file does not appear in git lfs ls-files, Git still sees it as a normal file, not an LFS-managed one.

This is the step many people skip. They assume that installing Git LFS alone retroactively fixes history, but it does not.

Understand the Tradeoffs of Rewriting History

History rewriting is safe only if you coordinate with anyone else using the branch. Once commits change, other clones will need to rebase, reset, or reclone.

That is why the right operational sequence is:

1. stop pushing more commits with the large file
2. migrate or rewrite the history
3. verify LFS tracking locally
4. force-push the corrected branch if necessary
5. tell collaborators what changed

Large-file cleanup is a history-management problem as much as a storage problem.

Common Pitfalls

• Installing Git LFS after the large file is already in commit history and assuming that is enough.
• Tracking the file pattern in .gitattributes but forgetting to recommit or migrate the existing file.
• Force-pushing rewritten history without coordinating with collaborators.
• Using Git LFS for files that should not live in Git at all, such as generated build artifacts.
• Skipping verification with git lfs ls-files before pushing.

Summary

• GitHub rejects normal Git blobs larger than 100 MB.
• Git LFS solves the problem only if the file is tracked as an LFS object, not a normal blob.
• If the large file is already committed, rewrite history with git lfs migrate import or an equivalent cleanup step.
• Verify the result before pushing.
• Treat the fix as both an LFS configuration task and a history-repair task.