Find what's making your repository huge

Does this match your situation?

• Cloning takes many minutes for a small codebase.
• .git is far larger than your working directory.
• A push is rejected for exceeding a file size limit.
• CI checkouts are slow and getting slower.

Step-by-step fix

1. Measure the damage

   size-pack is the number that matters — the compressed size of all history. Compare it to your working directory to see how disproportionate things are.

   step 1Copy

   git count-objects -vH
   du -sh .git
   

   Show the PowerShell (Windows) version

   PowerShell (Windows)Copy

   git count-objects -vH
   "{0:N1} MB" -f ((Get-ChildItem .git -Recurse -File | Measure-Object Length -Sum).Sum / 1MB)
   

2. List the biggest objects with their filenames

   This is the canonical recipe: enumerate every object, ask for its size, keep the blobs, sort, and take the top few. The fourth column is the path.

   step 2Copy

   git rev-list --objects --all |
     git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
     awk '/^blob/ {print $3, $4}' |
     sort -rn |
     head -20
   

   Show the PowerShell (Windows) version

   PowerShell (Windows)Copy

   git rev-list --objects --all |
     git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
     Where-Object { $_ -like 'blob*' } |
     ForEach-Object { $p = $_ -split ' '; [PSCustomObject]@{ Size = [long]$p[2]; Path = $p[3] } } |
     Sort-Object Size -Descending | Select-Object -First 20
   

3. Check whether the file still exists

   Often the culprit was deleted long ago and only survives in history. That's precisely why the repository never shrank when it was removed.

   step 3Copy

   git log --all --oneline -- "**/big-file.psd" | head
   ls -la big-file.psd 2>/dev/null || echo "not in the working tree - history only"
   

4. Purge the worst offenders from history

   Work on a fresh clone. Strip by size or by path, then force-push and have everyone re-clone.

   step 4Copy

   git clone --mirror . ../repo-backup.git
   pip install git-filter-repo
   
   git filter-repo --strip-blobs-bigger-than 25M
   # or by path:
   git filter-repo --path assets/huge.psd --invert-paths
   

   🚨Every hash after the affected commits changes. Teammates must re-clone, not pull.

5. Reclaim the space and prevent a repeat

   Garbage collection is what actually frees the disk. Then set up LFS so large binaries never enter history again.

   step 5Copy

   git reflog expire --expire=now --all
   git gc --prune=now --aggressive
   git count-objects -vH
   
   git lfs install
   git lfs track "*.psd" "*.fbx" "*.wav"
   git add .gitattributes
   

Why this works

Git keeps every version of every file forever, and binaries barely compress and change wholesale on each save, so a handful of large assets can dwarf years of source code. Deleting a file adds a commit in which it's absent, but every earlier commit still contains it and a clone downloads all of them. Only rewriting those commits removes the blob, and only garbage collection then reclaims the disk. LFS sidesteps the whole problem by storing a small pointer in Git and the payload elsewhere.

How to stop it happening again

• Set up Git LFS before committing binary assets, not after.
• Ignore build output and caches - for Unity that means Library/, Temp/, Build/ and Logs/.
• Add a pre-commit hook rejecting files over a size threshold.
• Check git count-objects -vH occasionally so bloat is caught early.

Commands used in this guide

Frequently asked questions