Blog Find large files bloating your git repo
Find large files bloating your git repo
TL;DR A slow-cloning repo usually has large files buried in its history, not just its current state. List the biggest objects in the packfile to find them. Removing them means rewriting history, which is disruptive, so weigh whether it is worth it and coordinate with your team first.
A repo that takes forever to clone is almost always carrying weight from the past: a large file committed once, long ago, that still sits in every clone even if it was later deleted. Git never forgets, which is usually a feature and occasionally a problem. Here is how to find the culprits.
Why deleting does not help
The first surprise people hit: deleting a big file does not shrink the repo. Git keeps every version of every file in history, so a large binary added in an old commit still lives there, and every clone still downloads it, even though the current tree no longer contains it.
To actually shrink the repo, you have to remove the file from history, not just from the latest commit.
Find the biggest objects
Before removing anything, find what is actually large. You can list the biggest objects stored in the repo's packfile, which reveals the heavy files hiding in history:
git rev-list --objects --all |
git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
sort -k3 -n | tail -20
That gives you the twenty largest objects with their sizes, the shortlist of what is bloating the repo.
Decide before you rewrite
Now the important part: removing a file from history rewrites that history. Every commit after the change gets a new hash, which means everyone has to re-clone or reset, references can break, and it is genuinely disruptive on a shared repo.
So weigh it. If the repo is painfully slow and the offending file is clearly junk, rewriting is worth the disruption, done deliberately, with a backup and the team informed. If it is a minor annoyance, the cost of rewriting may not be worth it.
The better long-term fix
Prevention beats cleanup. Keep large files out of git in the first place: use a pre-commit hook or a size check to block big binaries, put genuinely large assets behind large-file storage or an external store, and keep the repo to source. A repo that never accepts big files never needs the painful history rewrite.
The short version
A slow repo means large objects in history, not just in the tree. List the biggest objects to find them, and understand that removing them means rewriting history, which is disruptive enough to plan carefully. Then do the more valuable thing: set up guards so it does not happen again.
FAQ
Why is my git repo so large?
Usually because a large file was committed at some point and still lives in history, even if it was later deleted. Git keeps every version of everything, so a big binary added once inflates every clone forever until you rewrite history to remove it.
Does deleting a large file fix the repo size?
No. Deleting it in a new commit removes it from the current state but leaves every earlier version in history, so the repo stays large. Actually shrinking the repo means rewriting history to remove the file from all past commits.
Is it safe to rewrite git history to remove big files?
It works, but it is disruptive: it changes commit hashes, so everyone must re-clone or reset, and it can break references. Do it deliberately, coordinate with your team, and back up first. Often the better fix is preventing large files from being committed in the first place.