Git 3.0: qué cambia con SHA-256 y cómo probarlo hoy

Lo esencial

Git 3.0 hará de SHA-256 el algoritmo de hash por defecto, en lugar de SHA-1.
SHA-1 es vulnerable a colisiones desde SHAttered (2017) y Shambles (2020), aunque romperlo cuesta decenas de miles de dólares.
Un repositorio SHA-256 no es compatible con uno SHA-1: no se pueden fusionar ni empujar directamente entre ambos.
El hash SHA-256 pasa de 20 a 32 bytes (40 a 64 caracteres hex), lo que agranda cada objeto del repositorio.
Podés probar un repo SHA-256 hoy mismo con git init --object-format=sha256 desde Git 2.29 en adelante.

Cómo Git usa un hash para guardarlo todo

Git es lo que se llama una base de datos direccionable por contenido. Cada archivo, árbol de directorios y commit que guardás se identifica por el hash de su contenido, no por un nombre o un número de secuencia. Si dos archivos tienen exactamente el mismo contenido, Git los guarda una sola vez.

Ese hash también funciona como mecanismo de integridad: cada commit incluye el hash del commit anterior, así que cambiar un solo byte en un archivo de hace tres años rompe el hash de todos los commits posteriores. Desde que Linus Torvalds creó Git en 2005, ese hash es SHA-1.

Por qué SHA-1 ya no alcanza

SHA-1 produce un hash de 160 bits. Para que dos archivos distintos choquen por accidente harían falta, según el límite del cumpleaños, del orden de 1,4 septillones de archivos en un mismo proyecto. En la práctica, eso nunca pasó en ningún repositorio Git.

El problema no es el azar, sino el ataque deliberado. Investigadores demostraron colisiones reales con SHAttered en 2017 y SHA-1 is a Shambles en 2020. Con suficiente poder de GPU, estimado en decenas de miles de dólares de cómputo, se pueden fabricar dos archivos distintos que produzcan el mismo hash. Eso es lo que la criptografía llama un algoritmo roto: no imposible de vulnerar, sino posible con recursos finitos.

Qué cambia técnicamente con SHA-256

El plan está documentado en la transición oficial de función de hash de Git: a partir de Git 3.0, los repositorios nuevos usarán SHA-256 por defecto en lugar de SHA-1. SHA-256 produce un hash de 256 bits (32 bytes, 64 caracteres en hexadecimal) frente a los 160 bits (20 bytes, 40 caracteres) de SHA-1.

Ese cambio de tamaño se propaga a cada objeto del repositorio: commits, árboles y blobs. Un repositorio SHA-256 pesa más por objeto, aunque Git compensa parte de la diferencia con la compresión zlib que ya aplica al empaquetar objetos en packfiles.

Compatibilidad: por qué un repo SHA-1 y uno SHA-256 no se mezclan

Acá está el punto que más fricción genera. Un repositorio en SHA-256 no es compatible de forma directa con uno en SHA-1: no podés hacer git push ni git pull entre ambos sin pasar por una conversión explícita. El documento técnico de Git contempla interoperabilidad vía git fast-export y git fast-import, pero no una fusión transparente entre formatos.

El problema práctico es que buena parte del ecosistema (GitHub, GitLab, Bitbucket y buena parte de los pipelines de CI/CD) todavía no soporta repositorios SHA-256 de forma nativa. Si convertís tu repo local a SHA-256 hoy, no vas a poder empujarlo tal cual a GitHub: necesitás mantenerlo en SHA-1 en el remoto, o esperar a que la plataforma sume soporte.

Cómo probar un repositorio SHA-256 hoy mismo

No hace falta esperar a Git 3.0. Desde Git 2.29, publicado en 2020, el formato SHA-256 existe como función experimental. Para probarlo:

# crear un repo nuevo en formato SHA-256
git init --object-format=sha256 repo-sha256
cd repo-sha256

# confirmar qué formato está usando
git rev-parse --show-object-format
# -> sha256

echo "contenido de prueba" > archivo.txt
git add archivo.txt
git commit -m "primer commit en sha256"

# el hash del commit ahora tiene 64 caracteres hex, no 40
git rev-parse HEAD

Compará ese último hash con el de un repo normal creado con git init sin flags: el hash SHA-1 mide 40 caracteres y el SHA-256 mide 64. La opción --object-format está documentada en la referencia oficial de git init, donde figura marcada como experimental.

Git la marca como experimental a propósito: el formato en disco todavía puede cambiar entre versiones, así que no conviene usarla en repositorios de producción por ahora.

La polémica: ¿el cambio vale el costo?

El debate que reavivó el tema esta semana lo planteó un ingeniero que ayudó a fundar GitHub, en un post en el blog de GitButler. Su argumento es que forzar SHA-256 como default en Git 3.0 va a generar una migración costosa en herramientas, integraciones y hosting, para mitigar un riesgo que hoy es mayormente teórico: nadie demostró todavía un ataque de segunda preimagen práctico contra SHA-1, el único que de verdad permitiría sustituir un archivo legítimo sin que nadie lo note.

La contraparte es que la integridad de Git depende de que ningún archivo del historial se pueda falsificar, y esperar a que exista un exploit práctico antes de migrar deja la ventana abierta sin necesidad. Ninguna de las dos posturas inventa datos; la diferencia es cuánto riesgo teórico justifica una migración que todavía no tiene soporte completo en el ecosistema.

Conclusión

SHA-256 en Git no es una función que se activa sola: es un cambio de formato de repositorio que hoy convive, a medias, con un ecosistema que sigue corriendo sobre SHA-1. Podés probarlo en un repo de prueba con git init --object-format=sha256 ahora mismo, pero migrar un repositorio real todavía implica esperar a que tu hosting y tu CI lo soporten, o aceptar vivir en modo experimental.

📖 Versión extendida con más detalle: https://elsolitario.org/2026/10/02/sha-256-en-git-que-cambia-y-probarlo/?utm_source=telegraph&utm_medium=instant_view&utm_campaign=programacion