Skip to content
LatchkeyLatchkey home

Git push "exceeds GitHub's file size limit" (LFS not tracking) in CI

GitHub rejects a push because a file exceeds the 100 MB hard limit. The file was committed as regular git content; it needs to be tracked by LFS so only a pointer lands in the repository.

What this error means

A push (often from a CI bot committing artifacts) fails with "remote: error: File X is 145.00 MB; this exceeds GitHub's file size limit of 100.00 MB".

git-lfs
remote: error: File data/dump.sql is 145.00 MB; this exceeds GitHub's file size limit of 100.00 MB
remote: error: GH001: Large files detected. You may want to try Git Large File Storage
error: failed to push some refs to 'https://github.com/acme/app.git'

Common causes

The file is not covered by an LFS track pattern

No .gitattributes rule matches the path, so git stored the full content and the push hit the hard size limit.

The large blob is already in history

Even after adding tracking, the oversized object remains in an earlier commit, so the push still carries it.

How to fix it

Track the pattern and migrate history

  1. Add an LFS track rule for the file type and commit .gitattributes.
  2. Rewrite history so existing large blobs become pointers with git lfs migrate import.
  3. Force-push the rewritten branch.
Terminal
git lfs track "*.sql"
git add .gitattributes
git lfs migrate import --include="*.sql" --everything
git push --force-with-lease

Do not commit build artifacts at all

If CI generated the large file, publish it as a workflow artifact or release asset instead of committing it into the repo.

Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

.github/workflows/ci.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached

How to prevent it

  • Add LFS track rules before committing large file types.
  • Keep generated artifacts out of the repository entirely.
  • Run git lfs migrate info to spot large blobs in history.

Frequently asked questions

What causes Git push "exceeds GitHub's file size limit" (LFS not tracking) in CI?
There are 2 common causes: the file is not covered by an lfs track pattern and the large blob is already in history. No .gitattributes rule matches the path, so git stored the full content and the push hit the hard size limit.
How do I fix Git push "exceeds GitHub's file size limit" (LFS not tracking) in CI?
There are 2 fixes depending on which cause you have: track the pattern and migrate history and do not commit build artifacts at all. Work through them in order, since the first is the most common.
What does Git push "exceeds GitHub's file size limit" (LFS not tracking) in CI actually mean?
A push (often from a CI bot committing artifacts) fails with "remote: error: File X is 145.00 MB; this exceeds GitHub's file size limit of 100.00 MB".
How do I stop Git push "exceeds GitHub's file size limit" (LFS not tracking) in CI happening again?
Add LFS track rules before committing large file types. The prevention section lists 3 changes that keep it from recurring.

Related guides

References

Not every red build is your code. Latchkey repairs the ones that are not, on the runner. Start free → 30-day trial · No credit card