Tamaño repo Git🌎 Actualizado abril de 2026
Esta calculadora te permite estimar el tamaño total de un repositorio Git a partir de tres variables clave: cantidad de commits, cantidad de archivos y el peso promedio por archivo. Git no almacena solo el estado actual del proyecto, sino el historial completo de cambios (objetos blob, tree, commit y tag). Por eso, un repo con 1.000 commits y 500 archivos de ~120 KB promedio puede pesar fácilmente entre 50 y 80 MB. La fórmula base es: Tamaño ≈ (archivos × KB_promedio) + (commits × overhead_por_commit), donde el overhead típico de Git por commit ronda los 1–4 KB en objetos comprimidos. Usala para planificar almacenamiento en servidores, estimar tiempos de clonado, o definir si conviene usar Git LFS para archivos grandes.
Cuándo usar esta calculadora
- Planificar el espacio en disco o en un servidor de CI/CD (GitHub Actions, GitLab CI) antes de clonar un monorepo con miles de commits.
- Decidir si implementar Git LFS (Large File Storage) cuando el repo supera los 1–2 GB por tener assets binarios como imágenes PSD, videos o modelos 3D.
- Estimar el tiempo de clonado (git clone) en una conexión de 100 Mbps: un repo de 500 MB tarda ~40 segundos, uno de 5 GB puede tardar más de 7 minutos.
- Auditar repos corporativos que crecieron sin control para identificar si vale la pena hacer un git filter-repo para limpiar archivos grandes del historial.
Ejemplo de cálculo
- 1000 commits, 500 files
- ~60 MB
Cómo funciona
4 min de lecturaCómo se calcula
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:
Tamaño_working_tree = Archivos × KB_promedio
Tamaño_objetos_Git = (Archivos × KB_promedio × factor_compresión) + (Commits × overhead_commit)
factor_compresión ≈ 0.55 – 0.65 (texto puro ≈ 0.3, binarios ≈ 0.85)
overhead_commit ≈ 1 – 4 KB (promedio real: ~2 KB)
Tamaño_total_repo = Tamaño_working_tree + Tamaño_objetos_GitEjemplo concreto (el del enunciado):
git gc --aggressive: ≈ 55–65 MB ✓ (coincide con el ejemplo ~60 MB)---
Tabla de referencia
| Commits | Archivos | KB/archivo | Tipo de contenido | Tamaño estimado |
|---|---|---|---|---|
| 100 | 50 | 20 | App web pequeña | ~2–4 MB |
| 500 | 200 | 80 | Proyecto Python/Node | ~20–35 MB |
| 1.000 | 500 | 120 | Monorepo frontend | ~55–95 MB |
| 5.000 | 1.000 | 200 | App empresarial | ~400–700 MB |
| 20.000 | 3.000 | 500 | Kernel / framework grande | ~4–10 GB |
| 50.000 | 10.000 | 50 | Historial largo, texto puro | ~2–5 GB |
> Los tamaños son post-git gc. Sin recolección de basura pueden ser 2–3× mayores.
---
Casos típicos
Caso 1 — Proyecto frontend React (mediano)
git gc: ~32–38 MBCaso 2 — App móvil con assets de diseño
Caso 3 — Microservicio con historial limpio
---
Errores comunes
1. Confundir tamaño del working directory con tamaño del repo: el working tree (archivos actuales) puede ser 60 MB, pero la carpeta .git/ con todo el historial puede triplicar ese valor. Siempre analizá du -sh .git/.
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 objetos sueltos (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: Git comprime muy bien texto (factor ~0.25–0.35) pero casi nada los JPEG, MP4 o ZIP (factor ~0.95–1.0). Calcular con factor plano de 0.6 sobreestima repos de texto y subestima los de multimedia.
5. Olvidar el overhead de ramas y tags: cada branch y tag es un objeto de referencia. En repos con cientos de ramas activas esto puede sumar varios MB de refs y pack-refs que no se contabilizan en la estimación simple.
---
Calculadoras relacionadas
Preguntas frecuentes
¿Cuánto pesa un commit de Git en promedio?
Un objeto commit en Git ocupa entre 200 y 500 bytes sin comprimir (contiene hash del árbol, autor, fecha y mensaje). Comprimido con zlib en un pack-file, el overhead baja a 150–400 bytes. Sin embargo, cada commit también referencia objetos tree y blob, por lo que el costo real en historial ronda los 1–4 KB por commit dependiendo de cuántos archivos modifica. En repos muy activos con diffs grandes, puede superar los 10 KB por commit.
¿Qué es Git LFS y cuándo conviene usarlo?
Git LFS (Large File Storage) reemplaza archivos grandes en el repo por punteros de texto liviano (<200 bytes), mientras el binario real se almacena en un servidor externo. Se recomienda cuando archivos individuales superan los 50 MB o cuando el .git/ crece más de 1–2 GB. GitHub impone un límite de 100 MB por archivo en repos normales y recomienda LFS para archivos de diseño, audio, video o datasets. La instalación es git lfs install y el tracking con git lfs track '*.psd'.
¿Por qué el repo pesa más después de borrar archivos grandes?
En Git, borrar un archivo con git rm solo elimina su presencia en el working tree y en los commits futuros. El objeto blob original sigue en .git/objects/ y seguirá en el historial indefinidamente. Para eliminarlo físicamente hay que reescribir el historial con git filter-repo --path archivo --invert-paths (la herramienta recomendada actualmente, reemplazando al deprecado git filter-branch) y luego hacer un git gc --aggressive --prune=now.
¿Cuánto tarda en clonar un repo según su tamaño?
El tiempo de clonado depende del tamaño del pack-file que transfiere el servidor. En una conexión de 100 Mbps reales (~12 MB/s): un repo de 50 MB tarda ~4 segundos, uno de 500 MB tarda ~42 segundos, y uno de 5 GB puede tardar más de 7 minutos. GitHub y GitLab ofrecen --depth=1 (shallow clone) para clonar solo el último estado sin historial, reduciendo el tamaño transferido hasta un 90% en repos con historial largo.
¿Cómo medir el tamaño real de un repo en mi máquina?
En Linux/macOS usá du -sh .git/ para ver el peso de la carpeta Git y du -sh --exclude='.git' . para el working tree. En Windows: Get-ChildItem -Recurse | Measure-Object -Property Length -Sum. Para un análisis detallado de qué objetos ocupan más, git count-objects -vH muestra el conteo y tamaño de loose objects y pack-files. La herramienta git-sizer (de GitHub) da un reporte completo con advertencias automáticas.
¿Cuál es el límite de tamaño de repo en las plataformas más populares?
Los límites oficiales en 2025 son: GitHub recomienda repos <5 GB y bloquea push si superan 100 MB por archivo (soft limit de repo: 10 GB). GitLab.com (plan gratuito): 5 GB por repo. Bitbucket Cloud: 2 GB por repo. Azure DevOps: sin límite oficial, pero recomienda <10 GB. Superados estos umbrales, el rendimiento de operaciones como git log, git blame y los pipelines de CI/CD se degrada significativamente.
¿El factor de compresión de Git es igual para todos los archivos?
No. Git usa compresión zlib (deflate) que es muy eficiente con texto plano: archivos .js, .py, .html o .md se comprimen al 25–40% de su tamaño original. Los archivos ya comprimidos como JPEG, MP4, ZIP o PDF prácticamente no se comprimen (factor 0.95–1.0) porque ya tienen entropía alta. Por eso, commitear binarios multimedia es especialmente costoso: 100 MB de JPEG ocupan ~98 MB en el pack-file, mientras que 100 MB de código fuente Python ocupan ~30 MB.
¿Qué comando uso para ver qué archivos ocupan más espacio en el historial?
El comando git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | grep '^blob' | sort -t ' ' -k3 -rn | head -20 lista los 20 blobs más grandes del historial. Alternativamente, la herramienta git-sizer (open source de GitHub) o BFG Repo Cleaner tienen reportes más amigables. Estos análisis son el primer paso antes de limpiar el historial con git filter-repo.
Fuentes y referencias
Metodología y confianza
Contenido revisado por el equipo editorial de Hacé Cuentas, con apego a nuestra política editorial y metodología de cálculo.
Última revisión: 18 de abril de 2026. Los parámetros fiscales, legales y datos se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos. Leé nuestra política de privacidad.
Resultados orientativos. Para decisiones financieras, médicas o legales críticas, consultá con un profesional.