¿Cuánto pesa un repositorio Git? Calculá su tamaño
Estimá el tamaño de tu repo Git (working tree + .git/) por commits, archivos y KB promedio. Tabla de referencia, factor de compresión zlib real y consejos de optimización.
Ver cálculo paso a paso
.git/objects/.Esta calculadora estima el tamaño total del repo a partir de tres variables: cantidad de commits, cantidad de archivos, y el peso promedio por archivo. La fórmula aplica el factor de compresión zlib real de Git (aproximadamente 0.6 para código fuente) y suma el overhead de objetos de historial — commits, trees y blobs referenciales — que en repos típicos ronda los 1–4 KB por commit.
Lo que hace útil esta herramienta no es solo el número final, sino entender qué variable domina el crecimiento. En repos de código puro, el factor limitante suele ser el volumen de archivos y su peso. En repos que alguna vez tuvieron assets binarios (aunque los borraron), el historial es el culpable. La calculadora te ayuda a detectar cuál es tu caso antes de meterte a hacer un git filter-repo o configurar Git LFS.
Usala para dimensionar el almacenamiento en servidores propios, estimar tiempos de clonado en distintas conexiones, decidir si vale la pena migrar a una estructura de monorepo o multi-repo, o simplemente para entender por qué tu repo creció tanto en los últimos meses.
Cuándo usar esta calculadora
- Un equipo de desarrollo en Buenos Aires tiene un monorepo con 4.500 commits, 1.200 archivos fuente y promedio de 15 KB por archivo. La calculadora estima ~120 MB, lo que confirma que el clonado en una conexión de oficina de 50 Mbps tomará menos de 20 segundos — sin necesidad de shallow clone.
- Una agencia digital tiene un repo de WordPress con 800 commits pero los devs subieron themes con imágenes PNG sin comprimir: 2.000 archivos a 250 KB promedio. La estimación supera los 400 MB solo en working tree, más el historial acumulado — señal clara de que necesitan Git LFS o un .gitignore más estricto.
- Un freelancer que factura a empresa del exterior tiene un proyecto con 300 commits y 200 archivos de ~8 KB. La calculadora da ~5 MB — puede usar GitHub gratuito sin ningún problema y el clonado en cualquier conexión tarda segundos.
- Un equipo de data science commitió notebooks Jupyter con outputs incluidos: 150 archivos pero de 2 MB promedio. La estimación da ~180 MB, lo que les avisa que en 6 meses con el mismo ritmo van a superar el límite de 5 GB de GitLab.com gratuito.
- Una startup quiere migrar de SVN a Git y tiene 50.000 commits históricos con archivos promedio de 5 KB. La calculadora les dice que el repo resultante puede rondar los 500 MB–1 GB, lo que justifica contratar un plan pago de GitLab o configurar un servidor propio con GitLab CE.
- Un desarrollador trabaja con modelos de machine learning: 200 commits pero archivos
.pkly.h5de 80 MB promedio. La calculadora evidencia que el repo superaría los 10 GB, confirmando que necesitan Git LFS o almacenar los modelos en un bucket S3/GCS con referencias en el código. - Una empresa con repositorio corporativo en Azure DevOps tiene 10.000 commits, 3.000 archivos y promedio de 40 KB. La estimación de ~700 MB les permite planificar el crecimiento: en 2 años al mismo ritmo van a necesitar políticas de archivo o splitteo en sub-repos.
- Un equipo evalúa si conviene hacer shallow clone (
git clone --depth=1) en su pipeline de CI/CD. Con un repo estimado en 2 GB pero el último estado en solo 200 MB, la calculadora justifica implementar shallow clone y ahorrar un 90% del tiempo de checkout en cada build.
Factor de compresión zlib por tipo de archivo en Git
| Tipo de archivo | Factor zlib | Ejemplos |
|---|---|---|
| Código fuente | 0,25–0,40 | .js, .py, .ts, .html, .md |
| Config / YAML / JSON | 0,30–0,50 | package.json, .yml, .env |
| Datos mixtos | 0,55–0,65 | CSV, XML, logs |
| Imágenes PNG | 0,70–0,90 | .png (ya tiene compresión interna) |
| JPEG / MP4 / ZIP | 0,95–1,00 | Ya están comprimidos externamente |
| Binarios compilados | 0,80–0,95 | .exe, .dll, .so |
Fuente: Git - Internals: Git Objects (documentación oficial), git-scm.com. La calculadora usa 0,6 como promedio para repos de código típicos.
Cómo funciona
Cómo se calcula el tamaño de un repositorio Git
Git almacena cada versión de cada archivo como un objeto blob, comprimido con zlib. Los commits y árboles (trees) son objetos adicionales de menor tamaño. La estimación parte de esta fórmula:
Working tree = Archivos × KB_promedio
.git/ objetos = (Archivos × KB_promedio × 0,6) + (Commits × 2 KB)
Total repo = Working tree + .git/ objetos
Factor de compresión: ~0,6 para código fuente; ~0,95 para binarios (JPEG, MP4, ZIP)
Overhead por commit: ~2 KB promedio en repos típicosEjemplo verificado (1.000 commits, 500 archivos, 120 KB/archivo):
git gc --aggressive: ~55–65 MB)---
Tabla de referencia por tipo de proyecto
| Commits | Archivos | KB/archivo | Tipo de contenido | Working tree | .git/ | Total |
|---|---|---|---|---|---|---|
| 100 | 50 | 20 | App web pequeña | 1 MB | 1 MB | ~2 MB |
| 500 | 200 | 80 | Proyecto Python/Node | 15,6 MB | 9,8 MB | ~25 MB |
| 1.000 | 500 | 120 | Monorepo frontend | 58,6 MB | 37,1 MB | ~96 MB |
| 2.000 | 1.200 | 800 | App con assets diseño | 937 MB | 565 MB | ~1,5 GB |
| 5.000 | 1.000 | 200 | App empresarial | 195 MB | 127 MB | ~322 MB |
| 20.000 | 3.000 | 500 | Kernel / framework | 1,43 GB | 0,9 GB | ~2,3 GB |
| 50.000 | 10.000 | 50 | Historial largo, texto | 488 MB | 342 MB | ~830 MB |
> Los tamaños son estimaciones post-git gc. Sin recolección de basura pueden ser 1,5–3× mayores.
---
Cómo medir el tamaño real (comandos)
bash
# Tamaño total del directorio .git/
du -sh .git/
# Desglose de objetos y pack-files
git count-objects -vH
# Working tree (sin .git/)
du -sh --exclude='.git' .
# Número de commits
git rev-list --count HEAD
# Número de archivos rastreados
git ls-files | wc -l
# KB promedio por archivo (Linux/macOS)
git ls-files -z | xargs -0 du -k | awk '{sum+=$1; count++} END {print sum/count " KB promedio"}'
# Top 20 archivos más pesados en el historial completo
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | grep '^blob' | sort -t ' ' -k3 -rn | head -20---
Factor de compresión según tipo de archivo
| Tipo de archivo | Factor zlib | Ejemplos |
|---|---|---|
| Código fuente | 0,25–0,40 | .js, .py, .ts, .html, .md |
| Config / YAML / JSON | 0,30–0,50 | package.json, .yml, .env |
| Datos mixtos | 0,55–0,65 | CSV, XML, logs |
| Imágenes PNG | 0,70–0,90 | .png (ya tiene compresión) |
| JPEG / MP4 / ZIP | 0,95–1,00 | Ya están comprimidos |
| Binarios compilados | 0,80–0,95 | .exe, .dll, .so |
La calculadora usa 0,6 como promedio razonable para repos de código típicos.
---
Errores comunes al estimar el tamaño
1. Confundir working tree con el repo completo: el working tree (archivos actuales) puede ser 60 MB, pero la carpeta .git/ con todo el historial puede pesar tanto o más.
2. Ignorar archivos binarios en el historial: un archivo .psd de 50 MB commiteado por error y luego "borrado" sigue ocupando espacio en .git/objects/. La eliminación real requiere git filter-repo --path archivo.psd --invert-paths.
3. No correr git gc antes de medir: sin recolección de basura, los loose objects pueden inflar el repo 2–3×. Ejecutá git gc --aggressive --prune=now para obtener el tamaño real comprimido.
4. Subestimar el factor de compresión en binarios: JPEG, MP4 y ZIP ya están comprimidos; Git no los comprime más. Calcular con factor 0,6 sobreestima repos de código puro y subestima los que tienen multimedia.
Ejemplo: proyecto React mediano
Preguntas frecuentes
¿Cómo calcula Git el tamaño real de un repositorio?
.git/objects/: blobs (contenido de archivos), trees (estructura de directorios), commits (metadatos del snapshot) y tags. Cada objeto se comprime individualmente con zlib. Cuando hacés git gc o git push, Git agrupa objetos en pack-files usando delta compression: en vez de guardar dos versiones completas de un archivo, guarda la primera y solo las diferencias. El resultado final es que el .git/ suele pesar significativamente menos que la suma de todos los snapshots históricos — pero nunca menos que el estado actual completo.¿Cuánto overhead genera cada commit en el historial?
¿Por qué el repo sigue pesando igual aunque borré archivos grandes?
git rm y hacer commit solo elimina ese archivo del working tree futuro. El objeto blob original sigue en .git/objects/ porque es parte del historial — Git es inmutable por diseño. Para eliminarlo físicamente hay que reescribir el historial: la herramienta recomendada actualmente es git-filter-repo (el comando git filter-branch está deprecated desde Git 2.24). El proceso: git filter-repo --path archivo-grande.psd --invert-paths, luego todos los colaboradores deben re-clonar porque el historial cambió. No basta con git gc si los objetos siguen referenciados en el historial.¿Cuánto tarda en clonar un repo según su tamaño y conexión?
git clone --depth=1 --single-branch, que transfiere solo el estado actual sin historial — puede reducir el tamaño transferido hasta un 90% en repos con historial largo.¿Qué es Git LFS y cuándo conviene activarlo?
.git/ supera 1–2 GB por binarios. GitHub bloquea push de archivos mayores a 100 MB y recomienda LFS para diseño, audio, video o datasets de ML. La configuración básica: git lfs install una sola vez, luego git lfs track '*.psd' para cada tipo de archivo.¿Cómo encontrar qué archivos del historial ocupan más espacio?
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | grep '^blob' | sort -t ' ' -k3 -rn | head -20. Esto lista los 20 blobs más grandes de todo el historial con su tamaño y nombre. Alternativamente, git-sizer (herramienta open source de GitHub) genera un reporte con warnings automáticos sobre commits grandes, archivos gigantes y profundidad de historial.¿Cuáles son los límites de tamaño en GitHub, GitLab y Bitbucket?
¿Qué es un shallow clone y cuándo tiene sentido usarlo?
git clone --depth=N) descarga solo los últimos N commits del historial en vez del historial completo. Con --depth=1 solo bajás el estado actual del código — ideal para pipelines de CI/CD donde solo necesitás compilar y testear. Un repo de 2 GB puede clonarse en 200–300 MB con --depth=1. Las limitaciones: no podés hacer git log completo ni git blame histórico. Para recuperar el historial completo después: git fetch --unshallow. En CI/CD es casi siempre la optimización más impactante que podés hacer.¿El factor de compresión de Git es igual para código que para imágenes?
.js, .py, .ts, .html o .md se comprimen típicamente al 20–40% de su tamaño original. Los archivos ya comprimidos como JPEG, MP4, ZIP o PDF tienen entropía alta y prácticamente no se comprimen — factor 0,95–1,0. En la práctica: 100 MB de imágenes JPEG en el historial ocupan ~98 MB en el repo, mientras que 100 MB de código TypeScript pueden ocupar solo ~30 MB.¿Cómo medir el tamaño real de mi repo en distintos sistemas operativos?
du -sh .git/ muestra el peso del directorio Git (historial y objetos), du -sh --exclude='.git' . muestra el working tree actual. El comando git count-objects -vH da un breakdown de loose objects y pack-files con tamaños legibles. En Windows (PowerShell): (Get-ChildItem .git -Recurse | Measure-Object Length -Sum).Sum / 1MB te da el total en MB. Para análisis profundo, git-sizer (github.com/github/git-sizer) genera un reporte detallado.¿La estimación sirve para repos con muchos branches?
¿Cuándo conviene dividir un repo grande en múltiples repos?
Fuentes y referencias
Metodología y confianza
Calculadora de tecnología revisada por el equipo editorial de Hacé Cuentas, contrastada con Git - Internals: Git Objects (documentación oficial), según nuestra política editorial y metodología.
Última revisión: 22 de junio de 2026. Los parámetros se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos.
Resultados orientativos. Para decisiones críticas, consultá con un profesional.
Rodríguez, M. (2026). ¿Cuánto pesa un repositorio Git? Calculá su tamaño. Hacé Cuentas. https://hacecuentas.com/calculadora-tamano-repo-git-commits-branches
Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.