Última actualización: 2026-06-29

Cómo estima Git el tamaño de un repositorio

El espacio que ocupa un repositorio Git en disco y el volumen que se transfiere durante una clonación son magnitudes distintas. Comprender la relación entre el árbol de trabajo y el historial empaquetado permite tomar decisiones fundamentadas sobre estrategias de clonación, limpieza de ramas y configuración de almacenamiento.

El modelo de packfile

Git no almacena instantáneas completas de cada archivo en cada commit. En lugar de eso, representa los cambios como objetos blob, tree y commit que se empaquetan en ficheros de tipo packfile. El motor de empaquetado aplica dos niveles de compresión:

1. Codificación delta: en lugar de guardar la versión íntegra de un archivo modificado, Git almacena el delta respecto a una versión base.
2. Compresión zlib: sobre los datos delta se aplica compresión deflate, similar a la que usa el formato ZIP.

El tamaño resultante del historial empaquetado se aproxima mediante:

$H = N \times C \times r$

donde $N$ es el número de commits, $C$ es el volumen de datos modificados por commit antes de la compresión, y $r$ es la relación de compresión (fracción del dato crudo que se conserva tras el proceso).

El tamaño total de la clonación es:

$T = W + H$

siendo $W$ el tamaño del árbol de trabajo (todos los archivos rastreados en HEAD, sin incluir el directorio .git).

Variables del modelo

Árbol de trabajo ($W$). El volumen que ocupa el conjunto de archivos en la revisión actual. Se puede obtener con du -sh sobre el directorio del repositorio excluyendo .git, o con herramientas de análisis de repositorios como git-sizer.

Número de commits ($N$). El total de entradas en el historial. Se consulta con:

git rev-list --count HEAD

Cambio promedio por commit ($C$). El volumen de datos añadidos o modificados en una confirmación típica, antes de la compresión. Los repositorios de código fuente con predominio de texto se sitúan habitualmente entre 10 kB y 100 kB por commit. Los repositorios que incluyen activos binarios de gran tamaño (imágenes, modelos, archivos de audio) pueden superar 1 MB por commit, lo que eleva drásticamente el tamaño del historial.

Relación de compresión ($r$). La fracción del dato delta bruto que permanece tras la codificación y la compresión zlib. Un valor del 30 % significa que el packfile ocupa el 30 % del tamaño sin comprimir. Los repositorios de código logran habitualmente entre el 20 % y el 40 %; los repositorios con activos binarios o datos ya comprimidos pueden quedarse entre el 80 % y el 100 %.

Ejemplo de cálculo

Un repositorio con las siguientes características:

• Árbol de trabajo: 100 MB
• Commits: 5.000
• Cambio promedio por commit: 80 kB
• Relación de compresión: 30 %

Produce una estimación del historial:

$H = 5.000 \times 80\ \text{kB} \times 0{,}30 = 120.000\ \text{kB} = 117{,}2\ \text{MB}$

Y un tamaño total de clonación aproximado de:

$T = 100\ \text{MB} + 117{,}2\ \text{MB} \approx 217\ \text{MB}$

Cuándo el directorio .git supera al árbol de trabajo

En un repositorio nuevo con pocos commits, el directorio .git ocupa una fracción pequeña del total. A medida que el proyecto acumula historial, especialmente si se han realizado muchas modificaciones sobre los mismos archivos, el tamaño del packfile puede superar al árbol de trabajo. Repositorios con más de 10.000 commits y modificaciones frecuentes sobre archivos de tamaño medio presentan frecuentemente un historial que multiplica por dos o por tres el tamaño del árbol actual.

Los factores que aceleran el crecimiento del historial son:

• Archivos binarios (imágenes, ejecutables, paquetes) con poca o ninguna similitud delta entre versiones
• Archivos de texto de gran tamaño con cambios completos en lugar de ediciones locales
• Ramas de larga vida que se fusionan sin podar

Clonación superficial y clonación parcial

Git ofrece mecanismos para reducir el volumen transferido en una clonación cuando el historial completo no es necesario.

Clonación superficial (git clone --depth N): descarga únicamente los últimos $N$ commits. Para un repositorio con 10.000 commits, --depth 1 transfiere solo la instantánea de HEAD más una capa mínima de metadatos, equivalente aproximadamente al tamaño del árbol de trabajo. La reducción de ancho de banda puede superar el 90 % en repositorios con historial extenso. La clonación superficial puede ampliarse posteriormente:

git fetch --unshallow

Clonación parcial (git clone --filter=blob:none): descarga todos los metadatos del historial pero omite los blobs de objetos hasta que se necesitan. Es útil en entornos de integración continua donde se requiere el historial completo de commits pero no todos los contenidos de archivo.

git sparse-checkout: permite extraer únicamente un subconjunto de directorios del árbol de trabajo, lo que reduce el espacio en disco sin afectar a la integridad del historial.

Herramientas de diagnóstico

Para obtener el tamaño real del repositorio en lugar de una estimación:

# Resumen del estado de objetos (incluye packfiles)
git count-objects -vH

# Análisis detallado de tamaño por archivo y por extensión
git-sizer --verbose

# Listar los objetos más grandes del historial
git rev-list --objects --all \
  | git cat-file --batch-check='%(objectsize:disk) %(rest)' \
  | sort -rn \
  | head -20

La herramienta git-sizer proporciona un análisis estructurado que incluye el tamaño del árbol de trabajo, el historial y los blobs más voluminosos, y es la referencia más fiable para planificar estrategias de mantenimiento del repositorio.