Git Repo Size Estimate Calculator
Estimate the on-disk size of a Git repository from its working tree and commit history, so you can plan clone times and storage.
How it works
Working tree = files × avg file size · History ≈ commits × avg change × compression% · Total = working tree + history
A Git repository on disk is the working checkout plus the .git object database, which stores every version of every file compressed as deltas. The checkout size is roughly the number of files times their average size; the history grows with the number of commits and how much each one changes, but Git packs objects so the stored bytes are a fraction of the raw changes. A shallow clone (--depth 1) skips most of the history component, which is why it is dramatically smaller for old repos.
Worked example
For 2,000 files averaging 15 KB, the working tree is 30,000 KB ≈ 29.3 MB. With 500 commits each adding ~50 KB packed to 40%, history is 500 × 50 × 0.40 = 10,000 KB ≈ 9.8 MB, for about 39 MB total.
Frequently asked questions
Why is my .git folder bigger than my checkout?
Because .git keeps every historical version of every file. Repos with large binaries that changed often, or files that were committed then deleted, carry that weight forever unless you rewrite history. Running git gc repacks objects and can shrink it.
How can I clone faster without the full history?
Use a shallow clone: git clone --depth 1 fetches only the latest commit, skipping the history component of the size entirely. A partial or blobless clone (--filter=blob:none) fetches file contents on demand.
Does this include large files stored in Git LFS?
No. LFS-tracked files are replaced by small pointer files in the repo and stored separately, so count only the pointers here and size the LFS store on its own.
Related calculators
This calculator is for educational purposes. Double-check important results before acting on them.