Esta lección salda tres deudas del curso. En la lección 06-05 dijimos que si el problema no es código compartido sino binarios pesados, la respuesta no son los submódulos sino Git LFS. En la 08-04 apareció en .gitattributes una línea críptica —*.psd filter=lfs diff=lfs merge=lfs -text— y prometimos explicarla. Y en la 08-06, al analizar por qué los binarios grandes envenenan un repositorio, dijimos que la solución correcta era esta.

Aquí está, y llega en buen momento: el equipo de gestor-tareas va a incorporar recursos gráficos, un vídeo de demostración y los ficheros de diseño originales de componentes-ui. Carla ha añadido un mockup-panel.psd de 84 MB y ya lo ha modificado tres veces. El repositorio, que pesaba 4 MB, pesa ahora 250 MB, y Bruno tarda cuatro minutos en clonar lo que antes tardaba dos segundos.

Vamos a entender por qué ocurre eso —no por qué "los binarios son malos", sino qué hace exactamente Git con ellos—, cómo lo resuelve LFS, y sobre todo qué precio tiene, porque LFS no es gratis ni indoloro y hay que adoptarlo sabiendo dónde duele.

1. Por qué Git sufre con los binarios grandes
2. La aritmética del problema en gestor-tareas
3. Qué es Git LFS: la idea del puntero
4. Instalación y primer seguimiento
5. Cómo se refleja en .gitattributes
6. El puntero por dentro
7. Clonar, traer y no traer objetos
8. Comandos de inspección y mantenimiento
9. Migrar un repositorio que ya tiene binarios en el historial
10. Limitaciones y avisos que hay que conocer antes
11. Alternativas a LFS
12. Cuándo usar LFS y cuándo no

Hay que volver al modelo de datos de la lección 01-04, porque el problema no es una limitación arbitraria: es una consecuencia directa de cómo funciona Git.

Git no guarda diferencias. Guarda el contenido completo de cada versión de cada fichero, como un objeto blob identificado por el hash SHA-1 de su contenido. Cuando modificas un fichero y confirmas, no se guarda "lo que cambió": se guarda un blob nuevo con el fichero entero.

Con ficheros de texto esto no importa, y aquí está la clave: al empaquetar el repositorio, Git calcula deltas entre objetos parecidos. Un fichero app.js de 40 KB con cien versiones se comprime a una fracción minúscula, porque cada versión se guarda como "la anterior más estos cambios".

Tres razones que se acumulan:

El resultado: el delta entre dos versiones de un binario es tan grande como el propio binario. Se puede comprobar (lección 08-06):

Las columnas son: hash, tipo, tamaño real, tamaño en el paquete y desplazamiento. Los tres blobs del .psd ocupan casi 84 MB cada uno dentro del paquete: la compresión no ha logrado nada. Compáralo con el blob de texto de la última fila, que pasa de 41 KB a 8 KB.

Esto es lo que convierte un problema molesto en uno grave. Como vimos en la lección 08-05 con los secretos y en la 08-06 con el tamaño: borrar el fichero no elimina los objetos. Un git rm mockup-panel.psd crea un commit nuevo donde el fichero no está, pero los tres blobs de 84 MB siguen en la base de datos, alcanzables desde los commits antiguos, y todo el que clone se los descargará.

Sacarlos de verdad exige reescribir el historial con git filter-repo, con todas las consecuencias que estudiamos: cambian todos los hashes desde el punto reescrito, y todo el mundo tiene que recuperar el repositorio.

Y este es el argumento decisivo. El repositorio de Git es distribuido: cada clon tiene el historial completo. Que Carla añada 250 MB de historial significa que:

• Bruno, Ana y Diego descargan 250 MB al clonar.
• Cada trabajo de CI que clone descarga 250 MB (y hay muchos al día).
• Cada worktree y cada clon nuevo ocupa ese espacio en disco.
• git gc tarda más, git clone tarda más, y el servidor sirve más tráfico.

Un fichero grande no es un problema de quien lo añade. Es un impuesto sobre todo el equipo, cobrado para siempre.

Pongamos números concretos al caso de Carla, para tener la intuición del orden de magnitud:

El código —lo que de verdad es el proyecto— ocupa el 0,25 % del repositorio. El resto son binarios que casi nadie necesita en su copia de trabajo la mayoría de los días.

Ahí está la observación que justifica LFS: la mayoría de la gente, la mayoría del tiempo, solo necesita la última versión de esos ficheros, o ninguna. Ana, que trabaja en la lógica de app.js, no necesita las tres versiones del .psd; ni siquiera necesita la última. El servidor de CI que ejecuta las pruebas tampoco.

Git, por diseño, se lo da todo a todos. LFS rompe ese "todo a todos" solo para los ficheros que decidas.

Git LFS (Large File Storage) es una extensión de Git —no forma parte de Git, se instala aparte— construida sobre un mecanismo que Git sí trae de serie: los filtros de .gitattributes que vimos en la lección 08-04.

La idea completa cabe en una frase:

En lugar del fichero grande, en el repositorio se versiona un pequeño fichero de texto que dice dónde está el contenido. El contenido real vive en un almacén aparte y se descarga solo cuando hace falta.

Dos mecanismos independientes trabajando a la vez:

El filtro clean se ejecuta cuando el contenido entra en Git (git add). Recibe el fichero de 84 MB, calcula su hash SHA-256, guarda el contenido en la caché local de LFS y devuelve a Git un texto de tres líneas. Git versiona ese texto, que es lo que acaba en el blob.

El filtro smudge se ejecuta cuando el contenido sale de Git (git checkout). Recibe el puntero, busca el contenido por su hash (en la caché local o descargándolo del servidor) y escribe el fichero real en el disco.

El resultado es que trabajas exactamente igual que siempre. Abres el .psd, lo editas, git add, git commit, git push. Los filtros son invisibles. Lo que cambia es lo que se guarda en el historial: 130 bytes de texto en lugar de 84 MB de binario.

LFS es un binario aparte, y cada persona del equipo debe instalarlo:

Y después, una vez por máquina y por usuario:

Ese comando hace dos cosas concretas, y conviene saberlo porque explica muchos comportamientos:

1. Registra los filtros en la configuración global:

Es exactamente el mecanismo de filtros de la lección 08-04. filter.lfs.required true significa que si LFS no está instalado, Git falla en lugar de dejar punteros sueltos por el disco. Es lo que quieres.

2. Instala hooks en el repositorio (pre-push, post-checkout, post-commit, post-merge) que se encargan de subir y bajar los objetos en el momento adecuado. Son hooks (lección 06-01), con las mismas propiedades de siempre: viven en .git/hooks/ y no se distribuyen. Por eso quien clone el repositorio necesita haber ejecutado git lfs install en su máquina.

Las comillas son importantes: sin ellas, el shell expandiría *.psd a los ficheros existentes y se registrarían rutas concretas en lugar del patrón.

Ver lo que hay declarado:

Y dejar de seguir un patrón:

Ojo: untrack quita la regla para el futuro. Los ficheros ya convertidos en punteros en el historial siguen siendo punteros; para revertir eso hace falta reescribir el historial (apartado 9).

Aquí se cierra la promesa de la lección 08-04. git lfs track no guarda nada en un fichero propio: escribe en .gitattributes, el mismo fichero que ya conoces.

Desglosemos los cuatro atributos, que es exactamente lo que quedó pendiente:

El -text es el más fácil de pasar por alto y el que causa el daño más difícil de diagnosticar. Por eso git lfs track lo pone siempre.

Consecuencia práctica muy importante: .gitattributes es un fichero versionado. Cuando Carla lo confirma y lo envía, todo el equipo hereda la configuración de LFS automáticamente. No hay que decirle a nadie qué ficheros son de LFS: está en el repositorio. Eso es lo que hace que LFS sea utilizable en equipo, y es un buen ejemplo del principio de la lección anterior: la configuración compartida vive en el repositorio.

Lo que no viaja en el repositorio es la instalación de LFS ni sus hooks. Por eso el CONTRIBUTING.md (lección 10-01) debe decirlo en la primera línea.

Un detalle sutil: .gitattributes se aplica en el momento del git add. Si añades el .psd antes de declarar el patrón, se versiona como binario normal y ya está en el historial. Por eso la secuencia correcta es siempre:

Confirmar .gitattributes en un commit separado y anterior no es cosmética: garantiza que quien haga checkout de cualquier punto del historial tenga la configuración correcta antes de encontrarse los ficheros.

Vamos a mirar exactamente qué se guarda. En el disco, el fichero es normal:

Pero lo que Git tiene versionado es otra cosa:

Ciento treinta bytes. Eso es todo lo que hay en el historial de Git por cada versión del .psd. Tres líneas:

Fíjate en la elegancia conceptual: LFS aplica exactamente el mismo principio que Git —direccionamiento por contenido (lección 01-04)— pero un nivel más abajo. El contenido se identifica por su hash, es inmutable, y el mismo contenido nunca se guarda dos veces. LFS usa SHA-256 mientras Git (todavía) usa SHA-1, algo sobre lo que volveremos en la lección 10-06.

Para verlo desde más abajo, con fontanería (lección 09-06):

Ciento treinta bytes en la base de datos de objetos. Frente a 88.080.384. Esa es toda la lección.

Gracias al atributo diff=lfs:

Un diff útil dentro de lo posible: dice que el contenido ha cambiado y que el tamaño es el mismo. No dice qué ha cambiado en la imagen, porque eso Git no puede saberlo.

Y aquí conviene recordar el truco de la lección 08-04: se puede definir un controlador de diferencias textualizador para ciertos binarios, de modo que git diff muestre metadatos legibles:

No es una diferencia visual, pero saber que la imagen pasó de 1200×800 a 2400×1600 ya es información. Los dos mecanismos son compatibles: LFS gestiona el almacenamiento, textconv mejora la visualización.

Aquí está la mayor parte del valor práctico de LFS, y también sus rarezas.

Dos fases claramente separadas:

1. Receiving objects: el historial de Git. 2,14 MB. Incluye los cuatrocientos commits, todo el código y todos los punteros de todas las versiones.
2. Filtering content: LFS descargando el contenido real de los ficheros de la revisión extraída. 196 MB, dos ficheros.

La diferencia con el escenario sin LFS: sin él habrían sido 250 MB en la primera fase (todas las versiones de todo) más el tiempo de resolver deltas inútiles. Con LFS son 2 MB de historial más solo el contenido actual.

Para quien no necesita los binarios —la CI que ejecuta las pruebas, alguien que solo va a tocar app.js— hay una variable de entorno:

Esto desactiva el filtro smudge, así que los ficheros LFS quedan en el disco como punteros de texto:

Es una situación perfectamente válida y muy útil, pero hay que saber reconocerla, porque es el origen de la incidencia de soporte más habitual con LFS: alguien abre el .psd con su editor de imágenes y recibe un error incomprensible, sin entender que lo que tiene es un fichero de texto de 130 bytes.

Para dejarlo permanente en una máquina o repositorio concreto:

O de forma más limpia y moderna, para clonar sin contenido:

Y la distinción entre fetch y pull, que es la misma que en Git (lección 04-04):

Cuidado con git lfs fetch --all: descarga el contenido de todas las versiones de todos los ficheros LFS de toda la historia. Es exactamente lo que estabas evitando al adoptar LFS. Solo tiene sentido en dos casos: hacer una copia de seguridad completa, o preparar una migración a otro servidor.

Si en tu máquina nunca quieres los vídeos, se configura una vez:

Y para la CI, donde esto importa mucho más porque se ejecuta decenas de veces al día:

Ese lfs: false es la optimización con mejor retorno de todo el apartado. Si tienes cincuenta ejecuciones de CI al día y cada una se ahorra 196 MB de descarga, son casi 10 GB diarios de tráfico y varios minutos de espera acumulados.

La columna del medio es la más útil:

Variantes útiles:

Esa última línea revela un problema real: (File: ...) en lugar de (LFS: ...) significa que ese fichero no está siendo gestionado por LFS, probablemente porque se añadió antes de declarar el patrón. Es el primer sitio donde mirar cuando el repositorio crece sin explicación.

Muestra la versión, la URL del punto final de LFS, la ruta de la caché local y la configuración de filtros. Es el equivalente para LFS del git config --list --show-origin de la lección 09-06, y el primer comando que hay que ejecutar cuando algo no funciona.

La caché local de LFS (.git/lfs/objects/) va acumulando contenido de revisiones antiguas:

prune es conservador por diseño: solo borra objetos que estén confirmados y enviados al servidor, y conserva los de las revisiones recientes. Se controla con:

Ese pruneverifyremotealways merece activarse: comprueba contra el servidor que cada objeto está a salvo antes de eliminarlo de tu disco. Cuesta algo de tiempo y evita el único escenario en el que prune podría hacer daño.

Este comando no modifica nada: analiza el historial y dice qué extensiones ocupan cuánto. Es el punto de partida obligatorio de cualquier migración, y también un buen chequeo periódico.

Este es el caso de gestor-tareas: los .psd ya están dentro. Adoptar LFS ahora hace que los ficheros futuros sean punteros, pero los 250 MB del historial siguen ahí y todo el mundo los sigue descargando.

Para sacarlos hay que reescribir el historial. LFS trae su propia herramienta.

git lfs migrate import reescribe el historial. Cambian los hashes de todos los commits afectados y de todos sus descendientes. Es la regla de oro de la lección 05-01 en su versión más contundente, y exige exactamente la misma coordinación que la limpieza de secretos de la lección 08-05.

Consecuencias concretas:

• Todas las ramas y etiquetas que contengan commits reescritos apuntarán a objetos nuevos.
• Cualquiera con un clon tendrá una divergencia completa (lección 09-03).
• Las propuestas abiertas quedarán basadas en commits que ya no están en main.
• Las firmas de commits (08-05) se invalidan, porque el objeto firmado ya no es el mismo.

Paso 0: acordarlo con el equipo y elegir el momento.

No es un paso técnico y es el más importante. Se necesita una ventana en la que nadie tenga trabajo sin enviar. Ana avisa por escrito, se fija hora y se pide a todos que envíen y cierren sus propuestas.

Ese git log --branches --not --remotes es la comprobación exacta: lista los commits que existen en alguna rama local y en ningún remoto. Si sale vacío, no hay nada que perder.

Paso 1: copia de seguridad.

Paso 2: auditar.

Sirve para decidir qué patrones migrar. Migra por extensión, no por fichero concreto: es más robusto y captura también los ficheros que se renombraron por el camino.

Paso 3: ensayar en una copia.

Fíjate en que las etiquetas también se reescriben. v1.0.0 ya no apunta al mismo commit. Es la consecuencia de la inmutabilidad del modelo de datos: cambiar cualquier cosa en el historial cambia todo lo que cuelga de ello.

Paso 4: verificar el resultado del ensayo.

Esta última comprobación es la más tranquilizadora y casi nadie la hace. El hash del árbol de HEAD resume todo el contenido de la revisión. Si coincide con el del repositorio original... no coincidirá, precisamente porque los .psd ahora son punteros. Pero sí debe coincidir el de los subdirectorios que no contienen ficheros migrados:

Si esos dos hashes son iguales, la migración no ha tocado el código. Es una verificación criptográfica, no una impresión.

Paso 5: ejecutarlo de verdad y publicar.

El orden importa: primero el contenido LFS, después las referencias. Si publicas las referencias antes, habrá un intervalo en el que alguien puede clonar un repositorio cuyos punteros apuntan a objetos que aún no existen en el almacén.

--force-with-lease en lugar de --force, siempre (lección 09-03). Y si el servidor tiene main como rama protegida (07-06), habrá que desprotegerla temporalmente y volver a protegerla justo después. Anótalo en el guion, porque se olvida.

Paso 6: que todo el mundo recupere.

La instrucción para el equipo, idéntica a la de la limpieza de secretos:

Y para quien tuviera trabajo sin enviar en una rama local:

Ese rebase --onto es exactamente la técnica de la lección 09-03: coge los commits que hay entre el main viejo y la rama vieja, y los replanta sobre el main nuevo.

Paso 7: limpiar el servidor.

Reescribir el historial no libera espacio en el servidor por sí solo: los objetos antiguos siguen ahí mientras alguna referencia los alcance. Hay que pedir al servidor que ejecute su recolección de basura, y en muchas plataformas gestionadas eso es una petición al soporte. Averígualo antes de empezar, porque si no, el repositorio seguirá pesando lo mismo del lado del servidor y la migración parecerá haber fallado.

Convierte punteros de vuelta en ficheros normales. Útil si decides abandonar LFS. Requiere tener descargados los objetos, y reescribe el historial exactamente igual.

LFS resuelve un problema real, pero introduce otros. Estos son los que hay que conocer antes de adoptarlo, no después.

LFS no funciona sin servidor. El almacén es un servicio aparte que habla un protocolo propio sobre HTTPS. La mayoría de plataformas lo ofrecen; algunas instalaciones autoalojadas requieren configurarlo explícitamente.

Consecuencia inmediata: un repositorio con LFS deja de ser autocontenido. Si clonas un repositorio con LFS y el servidor de LFS no está disponible, tienes los punteros pero no el contenido. Esto choca de frente con la naturaleza distribuida de Git (lección 01-01), y es el argumento filosófico más serio contra LFS: has introducido un punto centralizado en un sistema distribuido.

Para una copia de seguridad realmente completa hacen falta dos cosas:

El almacenamiento LFS y su ancho de banda suelen tener cuotas de pago en las plataformas. Y hay una trampa que sorprende a mucha gente: el ancho de banda se consume también al descargar. Una CI que clona con lfs: true cincuenta veces al día puede agotar una cuota mensual en pocos días. De ahí la importancia del lfs: false del apartado 7.

Además, los objetos LFS de la historia no se borran solos. Si migras un fichero de 84 MB y luego lo eliminas, el objeto sigue ocupando cuota. Purgar el almacén es una operación específica de cada plataforma, no un comando de Git.

Hay diferencias reales entre implementaciones: cómo se gestionan los objetos en los forks, si el bloqueo de ficheros está disponible, cómo se aplican las cuotas, cómo se purgan los objetos huérfanos, y qué pasa al transferir un repositorio entre cuentas. No des por hecho que lo que funciona en una plataforma funciona igual en otra, sobre todo al migrar de proveedor: mover un repositorio con LFS de un servidor a otro requiere mover los objetos explícitamente.

Este es el más importante en el día a día. Cuando dos ramas modifican el mismo fichero LFS, hay conflicto siempre, y no se resuelve fusionando: hay que elegir una versión ganadora.

Y la resolución es la misma que para cualquier binario (lección 03-05):

Esos :2: y :3: son las etapas del índice que vimos en la lección 03-05 y en la 09-06: 1 es la base común, 2 "lo nuestro", 3 "lo suyo". Extraerlas permite abrirlas en la aplicación correspondiente y decidir con la información delante.

La consecuencia organizativa es que con binarios no se puede trabajar en paralelo. La solución real no es técnica sino de coordinación: que solo una persona toque cada fichero de diseño a la vez. LFS ofrece un mecanismo para formalizarlo, el bloqueo de ficheros:

Con --lockable, LFS marca esos ficheros como solo lectura en el disco hasta que los bloquees. Es un mecanismo de exclusión mutua, como en los sistemas centralizados (lección 01-01), y es la prueba de que para ciertos flujos ese modelo tenía sentido. Requiere soporte del servidor.

Si alguien clona sin LFS instalado y filter.lfs.required no está activo, obtendrá punteros de texto en lugar de ficheros, y —el peor caso— podría confirmar un fichero real encima de un puntero, rompiendo la coherencia. Con git lfs install bien hecho esto no ocurre, pero es la razón por la que la instalación debe ser lo primero del CONTRIBUTING.md.

• git checkout entre ramas con ficheros LFS distintos implica descargas.
• git bisect (06-02) sobre un historial con LFS puede descargar contenido en cada paso.
• Los worktree (06-06) comparten la caché LFS, lo cual es bueno, pero cada uno necesita su checkout.
• El smudge fichero a fichero puede ser lento; git lfs pull es más eficiente porque descarga en lote.

LFS no es la única respuesta, y a veces no es la mejor.

Antes de instalar nada, hazte tres preguntas:

1. ¿Es este fichero generado? Un .zip de distribución, un .png exportado desde un .svg, un ejecutable compilado. Si se puede regenerar, no debe estar en el repositorio (lección 08-03): va al .gitignore y lo produce la CI como artefacto.

2. ¿Necesito su historial? Un vídeo de demostración que se sustituye entero cada seis meses no gana nada versionado. Un .psd sobre el que se itera a diario y del que a veces hay que volver a la versión de la semana pasada, sí.

3. ¿Puedo versionar la fuente en vez del resultado? Un .svg es texto: se versiona, se diferencia y se fusiona perfectamente. Un .png de 4 MB exportado de ese .svg no aporta nada. Cambiar el formato de trabajo resuelve el problema mejor que cualquier herramienta.

Aplicado a gestor-tareas:

• Tienes ficheros binarios de más de unos pocos MB.
• Cambian con cierta frecuencia, generando muchas versiones.
• Necesitas su historial: hay que poder volver a una versión anterior.
• No son derivados de nada más pequeño que puedas versionar en su lugar.
• Tienes un servidor LFS disponible y presupuesto para su cuota.
• Todo el equipo puede instalarlo.

• Los ficheros son pequeños (menos de 1 MB): el puntero y la complejidad no compensan.
• Son generados: van al .gitignore.
• No necesitas el historial: guárdalos fuera con una referencia.
• Son texto, aunque sean grandes: Git los maneja bien con deltas y los fusiona.
• No tienes servidor LFS y no vas a tenerlo.
• El repositorio debe funcionar completamente sin conexión desde un solo clon.

La respuesta más frecuente en un proyecto como gestor-tareas es "no lo necesitas". Un repositorio de código puro con un puñado de iconos y un logo no tiene ningún problema que LFS resuelva. La necesidad aparece cuando entran ficheros de diseño, vídeo, audio, modelos 3D, conjuntos de datos o recursos de videojuego. En un repositorio de 50.000 ficheros con recursos gráficos, LFS es imprescindible; en uno de cuatro ficheros, es complejidad sin beneficio.

Error 1: adoptar LFS después de haber metido los binarios. Declarar el patrón solo afecta al futuro. Los objetos que ya están en el historial siguen ahí y siguen descargándose. Hace falta git lfs migrate import y una reescritura coordinada. Configura LFS el día que creas el repositorio, no cuando pesa 2 GB.

Error 2: olvidar el -text. Sin él, un * text=auto puede normalizar finales de línea en un binario y corromperlo. git lfs track lo pone; si editas .gitattributes a mano, no lo quites.

Error 3: confirmar los binarios antes que .gitattributes. Los filtros se aplican en el momento del add. .gitattributes primero, en su propio commit, y los binarios después.

Error 4: no darse cuenta de que se tienen punteros. Si un fichero de imagen pesa 130 bytes y empieza por version https://git-lfs..., es un puntero. Ejecuta git lfs pull. Comprobación rápida:

Error 5: dejar la CI descargando LFS sin necesitarlo. Es la vía más rápida de agotar la cuota de ancho de banda. lfs: false salvo en los trabajos que realmente necesitan los ficheros.

Error 6: git lfs fetch --all por costumbre. Descarga todo el historial de contenido, que es justo lo que LFS existe para evitar. Solo para copias de seguridad o migraciones.

Error 7: creer que un clon con LFS es una copia de seguridad completa. No lo es: te faltan los objetos LFS que no hayas descargado. Una copia real necesita el bundle y el contenido LFS.

Error 8: dos personas editando el mismo .psd a la vez. Terminará en conflicto irresoluble y alguien perderá trabajo. Usa --lockable y git lfs lock, o simplemente acordad quién toca qué.

Consejo 1: audita antes de decidir. git lfs migrate info --everything --above=1Mb te dice exactamente qué está inflando el repositorio, sin tocar nada.

Consejo 2: pon un límite de tamaño en la CI. Un guardián automático evita el problema de raíz (lección 07-06):

Consejo 3: documenta LFS en el CONTRIBUTING.md. Tres líneas al principio: instala git-lfs, ejecuta git lfs install, y si ves ficheros de 130 bytes, ejecuta git lfs pull. Ahorra la mitad de las preguntas de soporte.

Consejo 4: prueba la migración en un clon desechable. Siempre. Y verifica comparando el hash del árbol de los directorios de código antes y después: si coinciden, el código está intacto.

Consejo 5: git lfs prune de vez en cuando. La caché local crece sin límite. Con lfs.pruneverifyremotealways = true es una operación segura.

Diego clona gestor-tareas y obtiene esto:

Responde:

A. ¿Por qué mockup-panel.psd pesa 130 bytes y los otros dos no? B. ¿Por qué el repositorio ocupa 512 MB si supuestamente usan LFS? C. ¿Qué comandos ejecutarías para confirmar tu diagnóstico? D. ¿Cuál es la solución completa?

El equipo va a añadir a gestor-tareas:

• recursos/disenos/*.psd — ficheros de diseño, ~80 MB, cambian semanalmente, se itera sobre ellos
• recursos/video/demo.mp4 — 120 MB, se rehace entero cada seis meses
• recursos/iconos/*.svg — texto, unos pocos KB cada uno
• recursos/iconos/generados/*.png — exportados automáticamente de los SVG
• dist/gestor-tareas.zip — paquete de distribución, generado en cada versión

Escribe la secuencia completa de comandos y ficheros, decidiendo para cada tipo si va a LFS, a Git normal, al .gitignore o fuera del repositorio. Justifica cada decisión y respeta el orden correcto de los commits.

gestor-tareas lleva dos años con .psd y .mp4 versionados directamente. El repositorio pesa 3,2 GB. Se decide migrar a LFS.

Restricciones:

• Hay tres propuestas abiertas de Diego.
• main está protegida y exige revisión.
• Hay etiquetas v1.0.0 a v1.7.0, y v1.6.0 es lo que está en producción.
• Bruno tiene una rama local con cinco commits sin enviar.
• Los commits van firmados (08-05).

Escribe el plan completo, en orden, indicando qué pasa con cada restricción y qué comprobaciones harías. Señala en qué punto exacto el proceso es irreversible.

Solución 1

A. mockup-panel.psd es un puntero LFS; los otros dos son ficheros reales versionados directamente en Git.

Solo el primero fue declarado en .gitattributes antes de añadirlo. Los otros dos, o bien se añadieron antes de configurar LFS, o bien su patrón nunca se declaró.

B. Porque los 512 MB son los .psd y .mp4 que NO están en LFS, con todas sus versiones históricas. Adoptar LFS a medias no reduce nada: el repositorio sigue arrastrando todo lo que se metió antes o fuera de los patrones.

C. Diagnóstico paso a paso:

El paso 4 dará algo como:

Ese 9/12 es la pista clave: de doce ficheros .psd del historial, nueve están fuera de LFS.

D. Solución completa, en dos partes:

Parte 1: arreglar la configuración para el futuro.

Parte 2: limpiar el historial (reescritura coordinada, apartado 9).

Y avisar al equipo de que debe clonar de nuevo. Sin la parte 2 el repositorio seguirá pesando 512 MB para siempre, porque los objetos antiguos no desaparecen al cambiar la configuración.

Solución 2

Decisiones, con su motivo:

Sobre el .mp4: si el equipo prefiere versionarlo, LFS es una opción defendible. Pero al no necesitar su historial, guardarlo fuera evita consumir cuota con dos copias de 120 MB.

Secuencia completa, en el orden correcto:

Confirmar la configuración sola y antes es lo que garantiza que los filtros estén activos cuando lleguen los binarios.

Esta comprobación es la clave del ejercicio. Si dijera (File: ...) en lugar de (LFS: ...), el filtro no se habría aplicado y habría que deshacer el add, revisar .gitattributes y volver a empezar. Verificar aquí cuesta cinco segundos; descubrirlo después cuesta una reescritura de historial.

Y en el CONTRIBUTING.md:

Solución 3

Plan completo, por fases.

Fase 0 — Preparación (reversible).

Con este dato se decide si merece la pena. Reducir de 3,2 GB a ~150 MB, sí; a 2,8 GB, no.

Restricción — las tres propuestas de Diego: hay que cerrarlas antes. Se integran o se abandonan. Una propuesta basada en commits que van a dejar de existir queda inservible, y pedirle a un colaborador externo que rehaga tres ramas sobre un historial reescrito es una mala experiencia. Esta es la restricción que marca el calendario.

Restricción — la rama local de Bruno: que la envíe al servidor antes de la migración. Así se reescribirá junto con todo lo demás y no tendrá que reubicarla a mano. Si no puede, tendrá que hacer el rebase --onto del apartado 9.

Fase 1 — Copias de seguridad (reversible).

Y, si en algún momento se necesitaran los binarios originales, descargar el contenido antes de perderlo de vista.

Fase 2 — Ensayo (reversible).

Esa tabla de correspondencias hay que guardarla y publicarla: si alguien tiene apuntado que en producción está el commit 3f2a1b9, necesitará saber cuál es su equivalente nuevo.

Restricción — las firmas: al reescribir los commits, las firmas se invalidan y se pierden. El objeto commit cambia, así que la firma sobre el objeto anterior deja de ser válida. Hay que asumirlo y documentarlo: los commits anteriores a la migración quedarán sin firma verificable. Es un argumento serio para hacer la migración cuanto antes o no hacerla nunca, y una razón más para configurar LFS el primer día. Los commits posteriores se firmarán con normalidad.

Restricción — v1.6.0 en producción: la etiqueta cambiará de hash. Hay que comprobar qué apunta a ese commit en el sistema de despliegue (lección 10-05) y actualizarlo. Y verificar que la nueva v1.6.0 produce el mismo artefacto que la vieja: mismo código, distinto hash de commit.

Fase 3 — Ventana de migración (PUNTO IRREVERSIBLE).

El punto de no retorno es el git push --force-with-lease. Todo lo anterior es reversible. A partir de ahí, el servidor tiene el historial nuevo y cualquiera que clone o traiga cambios obtiene la versión reescrita. Volver atrás requiere restaurar desde la copia espejo y repetir el anuncio.

La rama protegida exige desprotegerla y volver a protegerla. Anótalo en el guion: es el paso que más se olvida, y dejar main desprotegida un fin de semana es un riesgo innecesario.

Fase 4 — Recuperación del equipo.

Mensaje al equipo:

Fase 5 — Cierre.

Y en el servidor: pedir la recolección de basura para que libere el espacio de los objetos antiguos. Sin este paso, el repositorio del servidor seguirá pesando 3,2 GB y la migración parecerá no haber servido de nada.

Por último, poner el guardián en la CI (consejo 2) para que esto no vuelva a pasar, y documentar LFS en el CONTRIBUTING.md.

Git es excelente para texto y pésimo para binarios grandes, y ahora sabes exactamente por qué: no es una limitación arbitraria, es una consecuencia del modelo de datos. Cada versión es un blob completo, los deltas no funcionan sobre contenido ya comprimido, los objetos son inmutables y todo el mundo se descarga el historial entero.

• Git LFS sustituye el fichero por un puntero de texto de unos 130 bytes —version, oid sha256:..., size— que sí se versiona bien, y guarda el contenido real en un almacén aparte. Funciona mediante los filtros clean y smudge de .gitattributes, el mismo mecanismo de la lección 08-04.
• La configuración vive en .gitattributes como filter=lfs diff=lfs merge=lfs -text: el filter hace la sustitución, diff y merge registran los controladores de LFS, y -text evita que la normalización de finales de línea corrompa el binario. Al estar versionada, todo el equipo la hereda; lo que no se hereda es la instalación de LFS.
• El orden importa: git lfs track, confirmar .gitattributes solo, y después añadir los binarios. Verificar siempre con git lfs status que dice (LFS: ...) y no (File: ...).
• Al clonar se descargan los punteros y solo el contenido de la revisión extraída. GIT_LFS_SKIP_SMUDGE=1 y lfs: false en la CI evitan descargas innecesarias; git lfs pull las trae cuando hacen falta. Y git lfs fetch --all descarga todo el historial de contenido: úsalo solo para copias de seguridad.
• git lfs migrate import reescribe el historial, con toda la fuerza de la regla de oro de la lección 05-01: cambian los hashes, cambian las etiquetas, se invalidan las firmas, y todo el mundo debe clonar de nuevo. Ensaya en una copia, verifica con el hash del árbol que el código no se ha tocado, publica primero el contenido LFS y después las referencias, y no olvides pedir la recolección de basura del servidor.
• Las limitaciones son reales y hay que conocerlas antes: hace falta servidor, las cuotas cuestan dinero (también el ancho de banda de descarga), las plataformas no se comportan igual, el clon deja de ser autónomo, y los ficheros LFS no se fusionan: hay que elegir versión ganadora, o coordinarse con --lockable y git lfs lock.
• Y hay alternativas: git annex para escenarios más flexibles, guardar el binario fuera con una referencia cuando no necesitas su historial, y sobre todo repensar el flujo: si el fichero es generado, va al .gitignore; si puedes versionar la fuente en lugar del resultado, hazlo.

La idea que resume la lección:

LFS no hace que Git maneje bien los binarios. Hace que Git deje de manejarlos, versionando en su lugar una referencia. Es una solución excelente cuando el binario es parte real del producto y necesitas su historial, y complejidad innecesaria en cualquier otro caso.

Para gestor-tareas, con sus cuatro ficheros de texto, LFS era irrelevante hasta ayer. Con la llegada de los ficheros de diseño ha pasado a ser necesario, y ha llegado justo a tiempo: configurarlo hoy cuesta dos commits; hacerlo dentro de un año habría costado una reescritura de historial y una tarde de coordinación.

LFS resuelve una de las tres formas en que un repositorio se vuelve inmanejable: los ficheros muy grandes. Quedan las otras dos, y son independientes.

Un repositorio puede tener muchísimo historial —veinte años y cientos de miles de commits— aunque cada fichero sea diminuto: clonarlo tarda una eternidad y git log se arrastra. Y puede tener muchísimos ficheros —cientos de miles en la copia de trabajo— aunque el historial sea corto: git status tarda medio minuto porque tiene que recorrer el árbol entero.

Cada una tiene su propio remedio, y ninguno sirve para las otras dos. Los clones parciales con --filter=blob:none atacan el volumen de contenido descargado. El sparse-checkout con índice disperso ataca el número de ficheros en el disco. El commit-graph ataca el coste de recorrer el historial. Y por encima de todo está la decisión que condiciona el resto: monorepo o multirrepo, la comparativa que la lección 06-05 dejó abierta y que el caso 3 de la 10-01 dejó pendiente de explicar.

La lección 10-04: Escalando Git para Proyectos Grandes cierra ambas promesas, y empieza por la única regla que importa en optimización: medir antes de tocar nada.