La próxima versión mayor de Git se presenta como una ruptura coordinada con varias decisiones de diseño de larga trayectoria, no como un simple incremento de versión. En su informe del 18 de septiembre de 2026, LWN señala que el proyecto está considerando Git 3.0 después del esperado lanzamiento de Git 2.56, y que los cambios sensibles en materia de compatibilidad se trasladarían a la versión mayor. La actualización del informe indica que la secuencia acordada es Git 2.98 en diciembre de 2026, Git 2.99 como versión con soporte a largo plazo en abril de 2027 y Git 3.0 al mismo tiempo. Esta secuencia la publica LWN; la documentación de Git aportada no la confirma de forma independiente.
El artículo examina cambios importantes en los objetos de los repositorios de Git, el almacenamiento de referencias y los requisitos de compilación, por lo que el emblema oficial del proyecto funciona como identificador directo. Crédito: git-scm.com.
El cambio más claro es la transición propuesta de SHA-1 a SHA-256 para los repositorios de Git. Git utiliza hashes para identificar archivos, árboles de directorios y confirmaciones, así como para verificar la cadena histórica. LWN explica que SHA-1 se considera débil y que, en principio, un ataque satisfactorio podría dificultar la confianza en el historial de un repositorio. Git ya incorpora defensas contra los ataques SHA-1 conocidos, y LWN informa de que el soporte no experimental de SHA-256 existe desde Git 2.42, lanzado en 2023. Estas afirmaciones describen la justificación de seguridad y la trayectoria de implementación; no demuestran que los repositorios SHA-1 existentes estén siendo comprometidos en la actualidad.
Por tanto, la cuestión práctica de la migración no es simplemente si SHA-256 es más robusto. Consiste en determinar si los repositorios, los servicios de alojamiento y las herramientas que rodean un proyecto pueden funcionar conjuntamente durante la transición. LWN informa de que GitLab y Forgejo ya admiten SHA-256, mientras que el material aportado no permite establecer con claridad el nivel de compatibilidad de GitHub. También señala que brian m. carlson, empleado de GitHub y colaborador en la transición, afirmó que pronto habría novedades sobre el tema y sugirió que podría ser apropiado denominar Git 3.0 a la próxima versión. Esta es la opinión atribuida a un participante, no un anuncio oficial de producto de GitHub ni una prueba de compatibilidad.
Reftable es el otro gran cambio de almacenamiento objeto de debate. En la actualidad, Git almacena referencias como ramas y etiquetas en archivos dentro de `.git/refs/`, junto con un mecanismo `packed-refs` que consolida algunas de ellas. Al informar de que el repositorio de Android supera las 800 000 referencias y de que los repositorios con muchas referencias pueden sufrir consultas costosas, LWN cita la documentación de reftable de Git. Reftable almacena las referencias en formato binario con el propósito de ocupar menos espacio y permitir accesos más rápidos. Git 2.45 hizo posible crear repositorios respaldados por reftable, pero la documentación aportada no establece que reftable sea ya la opción predeterminada.
El beneficio probable será operativo, más que visible para la mayoría de los usuarios: los repositorios grandes podrían gestionar sus referencias con mayor eficiencia. El riesgo probable aparece en los casos límite, cuando otro programa lee o escribe un repositorio sin utilizar el propio Git. LWN identifica libgit2 como una posible fuente de problemas de compatibilidad y después informa de que Patrick Steinhardt declaró que libgit2 había incorporado soporte para reftable y activado el soporte SHA-256 de forma predeterminada en agosto. Se trata de una actualización de desarrollo atribuida; respalda la afirmación de que se estaba preparando libgit2, pero no demuestra que todas las aplicaciones que lo integran hayan distribuido ya el soporte necesario.
Un tercer cambio propuesto es hacer obligatorio Rust para compilar Git. LWN informa de que Git cuenta con soporte experimental para Rust, pero ha dudado en exigir un compilador de Rust funcional. Si la propuesta se implementa, las plataformas sin las herramientas adecuadas de Rust ya no podrán compilar la nueva versión de Git. Las fuentes aportadas no especifican qué plataformas resultarían afectadas, qué versiones del compilador serían necesarias ni si las distribuciones derivadas ofrecerían alternativas. Por ello, la evidencia respalda la existencia y las consecuencias de la propuesta, pero no permite realizar una evaluación completa de la portabilidad.
Las pistas del debate plantean una distinción útil entre cambiar el formato de los objetos de un repositorio y reescribir su historial ordinario de confirmaciones. El material aportado no contiene suficiente documentación primaria para determinar si todos los repositorios SHA-1 deberán enviarse mediante una actualización forzada, cómo mostrarán los proveedores de alojamiento los repositorios migrados o cómo se comportarán los submódulos con formatos mixtos. Estas preguntas deben permanecer abiertas, en lugar de responderse a partir de comentarios anecdóticos. Lo que sí establece la evidencia es que el soporte SHA-256 ya existe, que la planificación de la versión mayor está vinculada al trabajo de compatibilidad y que la preparación de las plataformas de desarrollo y de las herramientas constituye una limitación central.
Para quienes mantienen repositorios importantes, la consecuencia inmediata es inventariar las dependencias, en vez de suponer que instalar Git 3.0 será transparente. Esto incluye proveedores de repositorios alojados, sistemas de integración continua, herramientas de copia de seguridad y archivado, software de revisión de código, integraciones con entornos de desarrollo y bibliotecas como libgit2. Los equipos también deberían distinguir entre un experimento local con SHA-256 o reftable y una migración coordinada que cambie la forma en que colaboradores y servicios intercambian datos de repositorios. Las fuentes aportadas no ofrecen un procedimiento universal de migración, por lo que cualquier plan de implementación debería esperar a la documentación correspondiente del proveedor y de las herramientas.
La salvedad más importante es el calendario. La actualización de LWN presenta una secuencia concreta de lanzamientos, pero el material no incluye un anuncio independiente ni un documento primario del proyecto Git que la confirme. Del mismo modo, la fecha exacta de publicación de la fuente queda clara en la firma visible de LWN —18 de septiembre de 2026—, mientras que la fecha de generación del paquete de fuentes es posterior y no debe tratarse como la fecha de publicación del artículo. La interpretación más prudente es que Git 3.0 representa una dirección planificada con un trabajo preparatorio considerable, no una transición completada cuya compatibilidad y calendario estén ya definidos.