La evolución de Git para la próxima década

• Git, usado por desarrolladores de todo el mundo, está impulsando cambios estructurales de cara a los próximos 10 años, con reformas clave centradas en seguridad, escalabilidad y usabilidad
• El cambio más visible es la transición de SHA-1 a SHA-256; aunque el uso de SHA-1 quedará prohibido para 2030, su adopción se está retrasando por la falta de soporte en el ecosistema
• Con la adopción de Reftable, se busca gestionar eficientemente cientos de millones de referencias y resolver limitaciones del sistema de archivos y problemas de concurrencia
• Para mejorar el manejo de archivos grandes, se están desarrollando Large-object promisors y una base de datos de objetos enchufable, que se están integrando de forma gradual a partir de Git 2.50
• Influido por sistemas emergentes de control de versiones como Jujutsu, Git busca dar soporte a flujos de trabajo modernos mediante una UI más simple y la incorporación de nuevos comandos

---

La necesidad de cambios en Git

• Desde su lanzamiento en 2005, Git se consolidó durante 20 años como una herramienta central de la que dependen millones de repositorios y muchísimos scripts
  • Sin embargo, cambios en el entorno como las vulnerabilidades de seguridad de SHA-1, el aumento de los repositorios grandes y la expansión de los pipelines de CI han dejado al descubierto límites estructurales
• En 2017, el ataque SHAttered de CWI y Google demostró la posibilidad de colisiones en SHA-1
  • Debido al aumento de la capacidad de cómputo con GPU, grandes organizaciones ya han alcanzado un nivel en el que pueden calcular colisiones de hash
• En lugar de un rediseño revolucionario, Git debe optar por una evolución gradual, impulsando cambios mientras mantiene la compatibilidad con el ecosistema existente

Transición a SHA-256

• Git 2.29 (octubre de 2020) agregó soporte para SHA-256, pero plataformas principales como GitHub todavía no lo soportan
  • Git, Dulwich y Forgejo ofrecen soporte completo; GitLab, go-git y libgit2 están en una etapa de soporte experimental
• Aunque SHA-1 se usa para una simple verificación de integridad, todo el ecosistema —incluyendo firmas, CI y scripts— funciona bajo el supuesto de resistencia a colisiones
• Regulaciones gubernamentales y corporativas exigen eliminar SHA-1 para 2030, y SHA-256 pasará a ser el valor predeterminado en Git 3.0
• Para facilitar la transición del ecosistema, se recomienda que los usuarios participen mediante pruebas de herramientas y solicitudes de soporte a los forges

Adopción de Reftable

• Git tradicionalmente usa una estructura de referencias sueltas que almacena cada referencia como un archivo individual
  • En repositorios con decenas de millones de referencias, esto resulta ineficiente y provoca problemas de distinción entre mayúsculas y minúsculas en el sistema de archivos e inconsistencias de concurrencia
• Reftable utiliza una estructura tabular basada en formato binario, que permite actualizaciones atómicas y una gestión eficiente de referencias
  • En el caso de un repositorio de GitLab con 20 millones de referencias, el archivo packed-refs existente requiere reescribir 2 GB
• En Git 3.0, Reftable pasará a ser el backend predeterminado, y se recomienda usar comandos de Git en lugar de acceder directamente a archivos

Mejora del manejo de archivos grandes

• Git es eficiente para comprimir archivos de texto, pero al modificar archivos binarios se vuelve ineficiente porque debe recrear el objeto completo
  • Según un análisis de GitLab, el 75% del espacio de los repositorios está ocupado por archivos binarios de 1 MB o más
• La función Large-object promisors permite guardar objetos grandes en un almacenamiento remoto separado y transferirlos mediante CDN o la API de S3
  • Entre Git 2.50 y 2.52 se completó la implementación del protocolo, y ya se encuentra en una etapa de uso posible del lado del cliente
• La base de datos de objetos enchufable introducirá un formato de almacenamiento específico para binarios con soporte para guardado incremental
  • En Git 2.53 se introdujo una interfaz de base de datos de objetos unificada, y para 2.54 se espera una prueba de concepto (PoC)

Mejoras en la interfaz de usuario

• Los comandos de Git han sido criticados durante mucho tiempo por su complejidad y falta de consistencia, mientras que Jujutsu (JJ), basado en Rust, ha surgido como alternativa
  • Jujutsu ofrece reubicación automática del historial, tratamiento de conflictos como datos y una forma de manejar commits como borradores
• Git está incorporando parte de las ventajas de Jujutsu sin romper los flujos de trabajo existentes
  • En Git 2.54 se prevé añadir los comandos git history split y git history reword
  • Más adelante se planea agregar más subcomandos de edición del historial
• Steinhardt enfatiza que Git está aprendiendo de la competencia, y que la modernización de la UI y la mejora de la usabilidad ya están en marcha

[GN⁺]

Comentarios en Hacker News

• Git es realmente software hermoso, pero también deja ver tal cual su complejidad centrada en programadores
  He intentado enseñarle Git a personas que no son desarrolladoras, y no lograron aprovechar por completo la sutil potencia de sus funciones
  Sitios como Learn Git Branching son excelentes recursos de aprendizaje. Ojalá ese tipo de UX estuviera integrado en la experiencia base de Git: cosas como valores predeterminados intuitivos y un flujo de aprendizaje gradual
  Hoy en día, con CLI de agentes como Claude, Codex y OpenCode, es fácil ofrecer esa experiencia. Pero si Git mismo ofreciera abstracciones más accesibles, sería mucho más sencillo

  • El problema no es que Git exponga la complejidad, sino que expresa esa complejidad con terminología y conceptos equivocados, además de una documentación desastrosa

• Tengo muchas ganas de ver Git 3.0, pero al mismo tiempo también estoy listo para decepcionarme de inmediato 😅
  jj les ha ayudado mucho a los usuarios de Git, porque demostró que es posible tener un frontend de VCS más intuitivo

  • Mientras más competencia haya, mejor estímulo recibe el ecosistema

• En GitLab vi un caso donde se reescribía un archivo packed-refs de 2 GB cada pocos segundos, y no entiendo “por qué demonios pasa eso”

  • Y siendo sinceros, ni siquiera sé si hay alguna razón por la que Git o esa persona deban preocuparse por una situación así

• Guardar archivos grandes fuera parece un paso hacia un modelo centralizado, pero va en contra de la filosofía de diseño original de Git

  • No necesariamente. Eso es solo un tema del modelo de direccionamiento y la interfaz. Puedes usar un repositorio central, pero también almacenamiento distribuido como IPFS
  • Exacto. Git es un DVCS, no un DVFS de propósito general. Yo necesitaba un DVFS para almacenar documentos, así que hice uno por mi cuenta. Es simple, rápido y funciona bien para ese propósito

• La transición para dejar atrás SHA1 está tomando demasiado tiempo
  La función hash debió haberse diseñado desde el principio con una estructura más modular

• Creo que Git necesita una función para rastrear licencias de software a nivel de commit

  • No entiendo del todo a qué te refieres, pero eso no es trabajo de Git. Git es solo un sistema de control de código fuente, y las funciones extra deberían implementarse con herramientas de extensión como git-annex
  • Git sería peor si tuviera algo así. Los commits ya pueden almacenar datos arbitrarios, así que el metadata que necesites puedes ponerlo simplemente en el commit y procesarlo con una herramienta aparte
  • Para código asistido por LLM, basta con usar trailers
    Ejemplo: Co-Authored-By: Whatever LLM, License: WTFPL