El futuro de los archivos grandes en Git es Git mismo

• El proyecto Git recientemente comenzó oficialmente a resolver por sí mismo el problema de gestionar archivos grandes
• Git LFS es una solución temporal que genera varios costos y dependencia del proveedor para los usuarios
• Con la función reciente de partial clone, ahora Git por sí solo puede reemplazar la mayor parte de lo que hacía LFS
• Hacia adelante, también se está preparando la integración en Git oficial de una nueva solución llamada large object promisor
• Con estos cambios, todo apunta a que la solución definitiva para gestionar archivos grandes no será una extensión externa, sino Git mismo

---

El problema de los archivos grandes en Git y lo que está cambiando

• Si Git tiene un mayor enemigo, son precisamente los archivos grandes
• Los archivos grandes hinchan el repositorio, ralentizan git clone y también afectan negativamente a la mayoría de los entornos de hosting

La llegada de Git LFS y sus límites

• En 2015, GitHub lanzó Git LFS para esquivar el problema de los archivos grandes
• Pero Git LFS en sí mismo añadió nueva complejidad y costos de almacenamiento

• La comunidad de Git ha estado pensando silenciosamente en el problema de fondo de los archivos grandes y, recientemente, las versiones oficiales de Git han comenzado a mostrar una nueva dirección para gestionarlos sin LFS

Lo que ya se puede hacer hoy: reemplazar Git LFS con partial clone

• Cómo funciona partial clone

  • Git LFS: los archivos grandes se dejan fuera del repositorio y se trabaja descargando solo los archivos necesarios
  • Git partial clone (introducido en 2017):
    • clona excluyendo blobs por encima del tamaño deseado con la opción --filter
    • solo descarga desde el servidor ese archivo grande cuando hace falta
      > Partial clone puede reducir el tiempo de descarga y el uso de disco porque evita descargar por adelantado [large binary assets] durante Clone y Fetch
      > - Partial Clone Design Notes, git-scm.com

• Qué comparten partial clone y LFS

  • 1. Checkout mínimo: recibe solo la versión más reciente y omite el historial completo del archivo
  • 2. Clonado rápido: como no hay transferencia de archivos grandes, clone es más veloz
  • 3. Configuración rápida: a diferencia de shallow clone, permite acceder al historial completo del proyecto

• Ejemplo de uso de partial clone

  • Caso real de velocidad de clonado y espacio en disco al clonar un repo con mucho historial de archivos PNG grandes:
    • con un clone normal tarda casi 4 minutos y ocupa 1.3GB
    • con partial clone y un límite de blobs de 100KB, se clona en 6 segundos y ocupa 49MB
    • frente al original, mejora del 97% en velocidad de clonado y reducción del 96% en tamaño del checkout

• Límites de partial clone

  • Cuando se necesita un dato filtrado (por ejemplo, git diff, git blame, git checkout), Git solicita el archivo al servidor
  • Esta es la misma característica que tiene Git LFS
  • En la práctica, rara vez hace falta usar blame sobre archivos binarios

Los problemas de Git LFS

• Alta dependencia del proveedor: la implementación de GitHub solo soporta sus propios servidores, lo que genera cobros y dependencia
• Problema de costos: almacenar 50GB en GitHub LFS cuesta $40 al año, frente a $13 en Amazon S3
• Difícil de revertir: una vez que se migra a LFS, no se puede volver atrás sin reescribir el historial
• Costo continuo de configuración: todos los colaboradores deben instalar LFS; si no lo hacen, ven archivos de metadatos en lugar de los archivos reales, lo que genera confusión

Lo que viene: Large Object Promisor

• Los archivos grandes también generan problemas de costos para las plataformas de hosting como GitHub y GitLab
• Git LFS reduce costos del servidor descargando archivos grandes a un CDN

• ¿Qué es Large Object Promisor?

  • A inicios de este año, Git hizo merge oficialmente de una función llamada large object promisor
  • Esta función reduce la carga de almacenamiento del lado del servidor de forma similar a LFS, pero disminuye mucho la complejidad para el usuario
    > Este esfuerzo tiene como objetivo mejorar el trabajo del lado del servidor, especialmente con blobs grandes ya comprimidos en formato binario
    > Es una solución alternativa a Git LFS
    > – Large Object Promisors, git-scm.com

• Cómo funciona

  • 1. El usuario hace push de archivos grandes al host de Git
  • 2. El host deriva esos archivos grandes a un promisor de backend
  • 3. Durante el clone, el host de Git entrega al cliente la información del promisor
  • 4. Cuando hace falta, el cliente descarga automáticamente los archivos grandes desde ese promisor

• Estado actual de adopción y retos

  • El promisor para objetos grandes sigue en desarrollo y parte del código fue mergeado en Git en marzo de 2025
  • En GitLab y otros proyectos se sigue discutiendo la implementación adicional y los problemas pendientes
  • Todavía falta tiempo para una adopción masiva
  • Por ahora, sigue siendo inevitable depender de Git LFS para almacenar archivos grandes
  • Cuando el promisor se masifique, también se espera que GitHub permita subir archivos de más de 100MB

Conclusión: el futuro de los archivos grandes en Git es Git

• El proyecto Git sigue pensando constantemente en el problema de los archivos grandes por ti
• Por ahora, todavía sigue siendo necesario usar Git LFS
• Pero a medida que evolucionen partial clone y large object promisors, Git LFS se volverá cada vez menos necesario, y pronto llegará una era en la que los archivos grandes podrán gestionarse fácilmente solo con Git
• En el futuro, el último obstáculo para usar archivos grandes en Git será únicamente la idea de meter una biblioteca de MP3 dentro del repositorio