Git Repo Size Calculator
Estimate your Git repository size from commits, files, and average file size. See the working tree, the .git/ store, the total in MB, and a reference table.
See step-by-step calculation
.git/ object store (the full compressed history). Working-tree size is simply your file count times the average file size. The .git/ store is roughly the working tree compressed (about 60% of it for typical source code, thanks to Git's delta + zlib packing) plus a small per-commit overhead (~2 KB each for refs, trees, and metadata). This calculator turns three numbers you already know — commits, tracked files, and average KB per file — into an estimate of your total repo size, so you can forecast clone times, size CI/CD runner disks, and decide when it's time for Git LFS or a shallow clone.When to use this calculator
- Forecasting GitHub/GitLab storage before migrating a large monorepo to a paid tier, so you know if you'll cross the 1 GB soft limit
- Right-sizing CI/CD runner disks: knowing a repo clones to ~2 GB lets you provision instances and avoid out-of-disk build failures
- Deciding when to move binaries (game assets, ML weights, design files) to Git LFS instead of bloating the history
- Estimating clone and fetch times for new team members or ephemeral build agents on slow connections
- Planning a
git filter-repoor BFG cleanup by quantifying how much history depth and large blobs add to the.git/folder
Git Repo Size Estimates by Profile (Formula: Working Tree = Files × Avg KB; .git/ = Working Tree × 0.6 + Commits × 2 KB)
| Repo profile | Commits | Files | Avg file size | Working tree | `.git/` store | Total estimated |
|---|---|---|---|---|---|---|
| Small hobby project | 200 | 80 | 15 KB | 1.2 MB | 1.1 MB | ~2.3 MB |
| Mid-size web app | 1,000 | 500 | 120 KB | 58.6 MB | 37.1 MB | ~96 MB |
| Documentation / Markdown site | 3,000 | 1,200 | 8 KB | 9.4 MB | 11.4 MB | ~21 MB |
| Large OSS project | 50,000 | 3,500 | 40 KB | 136.7 MB | 179.7 MB | ~316 MB |
| Monorepo with binaries | 5,000 | 10,000 | 500 KB | 4,883 MB | 2,939 MB | ~7.6 GB ⚠️ |
| ML repo with model weights | 300 | 200 | 80,000 KB | 15.3 GB | 9.2 GB | ~24 GB ⚠️ |
Fuente: Git SCM – Git Internals: Packfiles (git-scm.com) y GitHub Docs – Repository limits (docs.github.com). ⚠️ GitHub recomienda mantener repositorios bajo 1 GB, aconseja fuertemente no superar 5 GB, y bloquea archivos individuales mayores a 100 MiB sin Git LFS. Los repos con binarios (PNG, ZIP, modelos ML) no se benefician de la compresión delta; el factor 0.6 puede subestimar el tamaño real del .git/ en esos casos.
How it works
How It's Calculated
Git's size model has two distinct components: the working tree (your checked-out files) and the .git/ object store (the compressed history). This calculator estimates both:
Working Tree (KB) = Files × Avg_KB_per_File
.git/ Store (KB) = Working Tree × 0.6 + Commits × 2 KB
└─ packed snapshot ─┘ └─ per-commit overhead ┘
Total (KB) = Working Tree + .git/ Store
Total (MB) = Total (KB) / 1024Why 0.6? Git stores objects with zlib deflate compression and delta encoding between similar blobs. On plain-text source code this typically lands the packed history at roughly 50–65% of the raw working-tree size, so 0.6 is a good default for code-heavy repos. The +2 KB per commit term accounts for the commit object, its tree objects, and ref/metadata overhead.
When to adjust the factor (mentally):
.git/ factor can be even lower, 0.3–0.5, because delta compression is extremely effective..pt/.safetensors model files): Git cannot delta-compress already-compressed formats, so the factor approaches 1.0 and the history balloons. If your average file size is large, treat this estimate as a floor and plan for Git LFS.---
Reference Table
All rows use the calculator's formula (Working tree = Files × Avg_KB; .git/ ≈ 0.6 × working tree + 2 KB × commits):
| Repo profile | Commits | Files | Avg file | Working tree | .git/ store | Total |
|---|---|---|---|---|---|---|
| Small hobby project | 200 | 80 | 15 KB | 1.2 MB | 1.1 MB | ~2.3 MB |
| Mid-size web app | 1,000 | 500 | 120 KB | 58.6 MB | 37.1 MB | ~96 MB |
| Documentation / Markdown site | 3,000 | 1,200 | 8 KB | 9.4 MB | 11.4 MB | ~21 MB |
| Large OSS project | 50,000 | 3,500 | 40 KB | 136.7 MB | 179.7 MB | ~316 MB |
| Monorepo with binaries | 5,000 | 10,000 | 500 KB | 4,883 MB | 2,939 MB | ~7.6 GB ⚠️ |
| ML repo with model weights | 300 | 200 | 80,000 KB | 15.3 GB | 9.2 GB | ~24 GB ⚠️ |
> ⚠️ GitHub recommends keeping repositories under 1 GB, strongly recommends under 5 GB, warns on files over 50 MB, and blocks any single file over 100 MiB unless it's tracked with Git LFS.
---
Worked Cases
Case 1 — Standard SaaS web app
1,000 commits, 500 files (TypeScript/CSS/HTML), 120 KB average.
Working tree = 500 × 120 = 60,000 KB ≈ 58.6 MB
.git/ store = 60,000 × 0.6 + 1,000×2 = 38,000 KB ≈ 37.1 MB
Total ≈ 96 MBWell within the free tier. A full clone takes a few seconds on broadband.
Case 2 — Game repo with PNG assets
300 commits, 2,000 files, 2,048 KB (2 MB) average — mostly textures.
Working tree = 2,000 × 2,048 = 4,096,000 KB ≈ 4.0 GB
.git/ store = 4,096,000 × 0.6 + 600 = 2,458,200 KB ≈ 2.3 GB (real value higher — binaries don't compress)
Total ≈ 6.3 GB (estimate); in practice often worseAction: move binary assets to Git LFS now. Without it, every contributor clones gigabytes of un-deltifiable data.
Case 3 — Long-lived enterprise monorepo
50,000 commits, 8,000 mixed files, 50 KB average.
Working tree = 8,000 × 50 = 400,000 KB ≈ 390.6 MB
.git/ store = 400,000 × 0.6 + 100,000 = 340,000 KB ≈ 332 MB
Total ≈ 723 MBAction: use
git clone --filter=blob:none (partial clone) for CI to skip historical blobs, and run git filter-repo --analyze to find the biggest size contributors.---
How to Measure the Real Size
The calculator gives an estimate; these commands give the truth:
bash
git count-objects -vH # loose + packed object sizes
du -sh .git/ # actual .git/ on disk
du -sh --exclude=.git . # working tree only
git gc --aggressive # repack first for the true minimumOn the GitHub API,
GET /repos/{owner}/{repo} returns a size field in KB. On GitLab, see Settings → Usage Quotas → Storage.---
Common Mistakes
1. Measuring only the working tree. du -sh . excludes nothing, but many devs forget that .git/ can be larger than the checked-out code. Always run du -sh .git/ separately.
2. Assuming binaries compress like text. Git deltas source code 85–92%, but near 0% on PNG/JPEG/ZIP/.pt. Using a 0.6 factor on a binary-heavy repo underestimates .git/ by several times.
3. Ignoring git gc state. A repo that has never been packed can be 3–5× larger than one that has. Repack before measuring.
4. Confusing commits with snapshots. Git stores a new blob for every changed file in every commit; a repo touching 200 files per commit grows far faster than one touching 5.
5. Forgetting tags, stashes, and PR refs. Annotated tags, stashes, and refs/pull/ refs all add objects and can inflate .git/ in busy repos.
---
Related Calculators
Worked example: a mid-size web app
Frequently asked questions
How do I estimate my Git repository size?
.git/ store ≈ 0.6 × working tree (compressed history for code) + ~2 KB per commit. Add them and divide by 1,024 for MB. Example: 500 files × 120 KB = 58.6 MB working tree; .git/ = 60,000 × 0.6 + 1,000 × 2 = 37.1 MB; total ≈ 96 MB. For binary-heavy repos, raise the 0.6 factor toward 1.0.What is the average size of a Git repository?
.git/) is roughly 10–20 MB, but the average is pulled well above 200 MB by repos with binaries or long histories. Most active professional projects with 1,000–5,000 commits and no binary assets land in the 50–300 MB range.Does the number of branches affect repo size?
How does Git LFS change the size calculation?
.git/ instead of 500 MB, so clone and fetch get dramatically faster. The working tree still receives the full file on checkout. In the formula, treat LFS-tracked files as near-zero in the .git/ term.Why does GitHub warn about repositories over 1 GB?
What is a shallow clone and how much does it save?
git clone --depth=1 fetches only the latest snapshot instead of full history, cutting .git/ size by up to ~99% on long-lived repos. It's ideal for CI/CD that only builds HEAD. The trade-off: you can't run git log, git blame, or git bisect across history without fetching more commits.How do I check my actual repo size right now?
git count-objects -vH for a loose-vs-packed breakdown, du -sh .git/ for the object store, and du -sh --exclude=.git . for the working tree. On GitHub, GET /repos/{owner}/{repo} returns a size field in KB; on GitLab see Settings → Usage Quotas → Storage.Does `git gc` reduce repository size, and by how much?
git gc repacks loose objects into pack files with delta + zlib compression. On a repo that was never packed, git gc --aggressive can shrink .git/ by 40–70% for text-heavy code and 10–30% for binaries. Git auto-runs a light git gc --auto once loose objects exceed about 6,700.Why is my .git/ folder bigger than my actual code?
.git/ stores every version of every changed file, not just the current snapshot. A long history with many edits, plus large binaries that were committed once and later deleted (they stay in history forever), can make .git/ several times larger than the working tree. Use git filter-repo --analyze to find the biggest historical blobs.What compression does Git use internally?
Sources & references
Methodology & trust
Calculadora de tecnología revisada por el equipo editorial de Hacé Cuentas, contrastada con Git SCM – Git Internals: Packfiles (Official Documentation), según nuestra política editorial y metodología.
Última revisión: June 20, 2026. Los parámetros se verifican periódicamente con las fuentes citadas.
Calculations run 100% in your browser. We do not store or transmit your data.
Indicative results. For critical decisions, consult a professional.
Rodríguez, M. (2026). Git Repo Size Calculator. Hacé Cuentas. https://hacecuentas.com/git-repo-size-calculator
Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.