Git LFS vs. Git estándar: rendimiento para activos grandes

Git LFS vs. Git estándar se convierte en una pregunta real cuando tu repositorio comienza a contener activos binarios grandes. El código fuente generalmente se comprime y diferencia bien, pero los videos, archivos de diseño, texturas de juegos, archivos de modelo y conjuntos de datos grandes pueden hacer que las clonaciones sean lentas y que el historial sea difícil de limpiar.

Git Large File Storage, generalmente llamado Git LFS, mantiene el repositorio Git normal más ligero reemplazando archivos seleccionados con pequeños archivos puntero y almacenando el contenido real en un almacén de objetos LFS. Ese compromiso ayuda a muchos equipos, pero no es magia. Aún necesitas elegir los archivos correctos, confirmar las reglas de seguimiento y entender cuándo LFS descarga contenido.

El cuello de botella de rendimiento de Git estándar

Git estándar almacena el contenido confirmado en su base de datos de objetos y mantiene suficiente historial para reconstruir cada versión confirmada. Eso funciona muy bien para archivos de texto. Funciona mal cuando el mismo archivo binario de 200 MB cambia muchas veces.

Dos problemas aparecen rápidamente:

Los formatos binarios como JPEG, MP4, ZIP, PSD y artefactos compilados a menudo no se comprimen bien con delta.
Los archivos eliminados permanecen en el historial a menos que reescribas el historial.
Las nuevas clonaciones pagan por errores pasados porque el historial de Git aún contiene esos objetos antiguos.
Los comandos de mantenimiento del repositorio tienen más datos para inspeccionar y empaquetar.

Por ejemplo, si un equipo confirma un archivo de diseño exportado grande cada sprint, eliminar el archivo de la rama actual más tarde no elimina sus versiones anteriores del historial. Los nuevos desarrolladores y trabajadores de CI pueden seguir descargando datos que nadie usa activamente.

Introducción a Git Large File Storage (LFS)

Git LFS es una extensión que gestiona archivos seleccionados fuera de la base de datos de objetos Git normal. Tu repositorio mantiene un pequeño puntero de texto. El contenido real del archivo vive en el almacenamiento LFS proporcionado por tu host Git u otro servidor LFS.

El sistema de punteros

Un puntero LFS se ve así:

version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
size 104857600

Ese puntero es lo que Git normal ve. El cliente Git LFS descarga el contenido real del archivo cuando el checkout o un comando LFS explícito lo necesita.

Comparación de rendimiento: LFS vs. Git estándar

Operación	Git estándar	Git LFS
Clonación inicial	Descarga el historial de Git que incluye objetos grandes confirmados	Descarga el historial de Git con archivos puntero; el contenido LFS puede descargarse durante el checkout según la configuración
Crecimiento del repositorio	Los binarios grandes pueden inflar el historial de `.git`	El historial de Git se mantiene más pequeño porque el contenido de los archivos rastreados es externo
Checkout	Utiliza objetos ya en la base de datos de Git	Puede necesitar obtener objetos LFS para el commit verificado
Trabajos de CI	Puede perder tiempo descargando activos históricos	Puede omitir o limitar las descargas LFS cuando las compilaciones no necesitan activos
Limpieza	Requiere reescribir el historial para eliminar blobs antiguos confirmados	Aún requiere cuidado, pero las nuevas versiones rastreadas por LFS no inflan el historial normal de Git

El detalle importante es el comportamiento del checkout. Un git clone simple con Git LFS instalado a menudo descarga los archivos LFS necesarios para el commit verificado. Si solo quieres punteros, usa GIT_LFS_SKIP_SMUDGE=1 durante la clonación y obtén los archivos más tarde con git lfs pull.

Cuándo usar Git LFS

Git LFS es adecuado para archivos que son grandes, binarios y se espera que cambien. Ejemplos comunes incluyen:

*.psd, *.tiff, *.blend y otros activos de diseño o 3D.
*.mp4, *.mov, *.wav y otros archivos multimedia.
Archivos de modelo grandes, fixtures de prueba o conjuntos de datos requeridos por el proyecto.
Binarios compilados solo cuando el proyecto tiene una razón clara para versionarlos.

No pongas todos los archivos en LFS solo porque puedas. Los archivos de texto, código fuente, archivos de configuración pequeños y archivos que quieras que Git diferencie normalmente deben permanecer en Git estándar.

Verifica los límites de almacenamiento y ancho de banda de tu proveedor de alojamiento antes de adoptar LFS. GitHub, GitLab, Bitbucket y plataformas autoalojadas pueden diferir en cuotas, facturación y comportamiento de retención.

Implementando Git LFS

Instala el cliente Git LFS, luego habilita sus hooks para tu usuario:

git lfs install

Rastrea los patrones que quieres que LFS gestione:

git lfs track "*.psd"
git lfs track "assets/*.mp4"

Esos comandos crean o actualizan .gitattributes. Confirma ese archivo junto con los activos que afecta:

git add .gitattributes assets/
git commit -m "Rastrear activos de diseño con Git LFS"
git push

Si un archivo grande ya fue confirmado en el historial normal de Git, rastrearlo con LFS solo afecta a futuras confirmaciones. Para migrar el historial existente, usa una herramienta de migración como git lfs migrate import, y coordina cuidadosamente porque reescribir el historial cambia los IDs de confirmación.

Para clonar sin descargar contenido LFS inmediatamente, usa:

GIT_LFS_SKIP_SMUDGE=1 git clone [email protected]:example/assets-heavy-repo.git
cd assets-heavy-repo
git lfs pull --include="assets/*.mp4"

Conclusión práctica

Usa Git estándar para código fuente y archivos de texto pequeños. Usa Git LFS para activos binarios grandes que pertenecen al repositorio pero no deben inflar el historial normal de Git.

Para un repositorio de equipo, agrega reglas LFS temprano, confirma .gitattributes, documenta cómo CI maneja las descargas LFS y verifica los límites LFS de tu host. Eso te da el beneficio de rendimiento sin sorprender a los desarrolladores durante la clonación, el checkout o las compilaciones de lanzamiento.