SHA-256 en Git: qué cambia y cómo probarlo hoy mismo

⏱️ Lectura: 16 min

Para 2026, Git sigue usando SHA-1 por defecto para identificar cada commit, blob y árbol, aunque ese algoritmo está marcado como criptográficamente roto desde 2017. Scott Chacon, cofundador de GitButler, publicó una crítica dura al plan de Git 3.0. Según su argumento, adoptar SHA-256 en Git como formato de hash por defecto generaría repositorios que GitHub y GitLab todavía no pueden alojar, sin un beneficio práctico para la mayoría de los proyectos.

📑 En este artículo

1. TL;DR
2. ¿Qué es SHA-256 en Git?
3. Por qué SHA-1 dejó de ser suficiente
4. Cómo funciona el cambio de hash en Git
   1. Qué cambia en el tamaño de los objetos
   2. Compatibilidad e interoperabilidad hoy
   3. Por qué SHA-256 y no otro algoritmo
5. Ejemplos prácticos: probar SHA-256 en tu máquina
   1. Crear un repositorio nuevo con SHA-256
   2. Calcular un hash SHA-256 de un archivo
6. Cómo empezar: probar un repositorio SHA-256 paso a paso
7. Casos de uso reales para el formato SHA-256
8. Errores comunes al probar el formato SHA-256
9. Comparativa: SHA-1 frente a SHA-256
10. Profundizando: el plan oficial de transición de hash
11. Preguntas frecuentes
    1. ¿Puedo migrar un repositorio SHA-1 existente a SHA-256 en Git sin perder el historial?
    2. ¿GitHub o GitLab aceptan repositorios con el algoritmo SHA-256?
    3. ¿Qué le pasa a un submódulo de Git si su formato de hash es distinto al del superproyecto?
    4. ¿Cuándo pasará SHA-256 a ser el formato de hash por defecto en Git?
    5. ¿Cómo confirmo si un repositorio local usa SHA-1 o SHA-256?
    6. ¿El algoritmo SHA-256 hace que verificar commits firmados sea más lento?
12. Referencias
    1. 📚 Artículos relacionados

La polémica sirve de gancho, pero el tema de fondo es técnico: qué cambia realmente ese algoritmo, qué tan compatible es con el ecosistema actual y cómo probarlo hoy mismo en tu propia máquina.

TL;DR

• Git soporta SHA-256 de forma experimental desde la versión 2.29 mediante git init --object-format=sha256.
• GitHub y GitLab todavía no alojan repositorios SHA-256: hoy no existe un git push directo a esos servicios.
• El hash pasa de 40 a 64 caracteres hexadecimales, lo que agranda ligeramente árboles y commits con muchas referencias.
• No existe una conversión oficial que preserve los hashes al migrar un repositorio SHA-1 existente a SHA-256.
• git rev-parse --show-object-format confirma en segundos qué algoritmo usa cualquier repositorio local.

¿Qué es SHA-256 en Git?

SHA-256 en Git es el algoritmo de hash alternativo a SHA-1 que la documentación oficial del proyecto define como el nuevo formato de objeto de 256 bits, capaz de identificar cada commit, árbol y blob con mayor margen criptográfico, y que cualquier repositorio puede adoptar hoy de forma experimental al momento de inicializarse.

El proyecto lo documenta en su plan técnico de transición, hash-function-transition, publicado dentro del propio repositorio de Git. Ese documento explica por qué SHA-1 ya no alcanza como garantía de integridad y qué pasos planea el proyecto para migrar sin romper la historia de millones de repositorios existentes.

Por qué SHA-1 dejó de ser suficiente

Git es lo que se llama una base de datos direccionable por contenido: cada archivo, cada árbol de directorios y cada commit se identifica por el hash de su contenido, no por un número arbitrario. Esa propiedad es la que le da integridad. Cambiar un solo byte en un commit antiguo cambia su hash, y ese cambio se propaga a todos los commits posteriores porque cada uno incluye el hash de su padre.

Desde que Linus Torvalds eligió SHA-1 en 2005, ese diseño funcionó sin incidentes conocidos de colisión accidental. El problema no es la casualidad, sino el ataque deliberado. En 2017, el equipo de Google y CWI Amsterdam publicó SHAttered, la primera colisión práctica de SHA-1: dos archivos PDF distintos con el mismo hash. En 2020, el paper SHA-1 is a Shambles abarató todavía más el ataque, al punto de volverlo viable con GPUs alquiladas en la nube en vez de supercomputadoras dedicadas.

Eso no significa que un commit de Git se pueda falsificar mañana con facilidad: un ataque práctico contra un repositorio real todavía exige condiciones específicas en el contenido manipulado. Pero sí significa que SHA-1 dejó de cumplir el estándar que la criptografía moderna exige para un hash de integridad, y que Git necesita un reemplazo antes de que la ventana de ataque se abarate más.

Cómo funciona el cambio de hash en Git

Git no reemplaza un algoritmo por otro dentro del mismo repositorio. En cambio, define un formato de repositorio nuevo. Cuando corrés git init --object-format=sha256, Git crea una carpeta .git cuyo archivo de configuración incluye la sección [extensions] objectFormat = sha256. Esa marca le dice a cualquier versión de Git que abra ese repositorio que use SHA-256 para todo: calcular hashes de blobs, armar árboles, firmar commits y escribir el pack de objetos.

Qué cambia en el tamaño de los objetos

La diferencia más visible es la longitud del hash. SHA-1 produce 160 bits, representados como 40 caracteres hexadecimales; SHA-256 produce 256 bits, representados como 64 caracteres. Un commit o un árbol que referencia a otros objetos guarda esas referencias como texto, así que cada referencia interna crece de 40 a 64 bytes.

El efecto es más notorio en árboles con muchos archivos y en historiales largos. Un monorepo con decenas de miles de archivos por commit ve crecer el tamaño de cada objeto tree en proporción directa a esa diferencia de 24 bytes por entrada. Para un blob individual, en cambio, el cambio es insignificante, porque el contenido del archivo no cambia, solo su identificador.

Compatibilidad e interoperabilidad hoy

Acá está el núcleo técnico de la crítica de GitButler. Un repositorio SHA-1 y uno SHA-256 no son intercambiables: no podés hacer git push ni git pull entre ambos sin pasar por una conversión, y Git todavía no incluye en su rama estable una herramienta que preserve los hashes originales al migrar.

El documento oficial hash-function-transition describe el diseño pensado para resolver esto: una tabla de traducción que mapea cada identificador SHA-1 a su equivalente SHA-256 y viceversa, para que un repositorio pueda hablar ambos formatos durante la transición. Ese mecanismo sigue siendo, en gran parte, un plan documentado más que una función lista para producción en todos los flujos de trabajo.

flowchart TD
    A["Repositorio SHA-1"] -->|"git push / git pull"| B["Remoto SHA-1, GitHub o GitLab"]
    C["Repositorio SHA-256"] -.->|"sin soporte nativo hoy"| B
    C -->|"git push / git pull"| D["Remoto SHA-256, self-hosted"]
    subgraph Hosting disponible en 2026
    B
    end
    subgraph Hosting experimental
    D
    end

Por qué SHA-256 y no otro algoritmo

El propio documento de transición explica el criterio de selección. SHA-256 es un estándar NIST ya validado, con implementaciones maduras en todas las bibliotecas criptográficas y con aceleración por hardware disponible en procesadores modernos a través de las extensiones SHA de Intel y ARM. Alternativas como BLAKE2 o SHA-3 también cumplían el nivel de seguridad necesario, pero priorizar un algoritmo ya omnipresente reducía la fricción de adopción en el ecosistema completo de herramientas que rodean a Git.

Ejemplos prácticos: probar SHA-256 en tu máquina

No hace falta esperar a Git 3.0 para experimentar. El soporte de --object-format=sha256 existe desde Git 2.29, lanzado en 2020, así que cualquier instalación reciente ya lo trae. Lo único que cambia con Git 3.0 es que dejaría de ser una opción explícita para convertirse en el valor por defecto.

Crear un repositorio nuevo con SHA-256

git init --object-format=sha256 repo-sha256
cd repo-sha256

Git responde con la confirmación estándar de inicialización:

Initialized empty Git repository in /home/dev/repo-sha256/.git/

Para confirmar qué algoritmo quedó activo, sin confiar en la memoria, Git expone un comando dedicado:

git rev-parse --show-object-format

La salida es una sola palabra con el nombre del algoritmo:

sha256

Si corrés el mismo comando en un repositorio creado sin la bandera --object-format, la salida es sha1: ese es hoy el valor por defecto en cualquier instalación estándar de Git, el mismo que GitButler no quiere ver reemplazado sin un camino de interoperabilidad resuelto.

Calcular un hash SHA-256 de un archivo

Dentro de ese mismo repositorio, cualquier operación normal usa SHA-256 de forma transparente. git hash-object lo deja explícito:

echo "hola mundo" | git hash-object --stdin

En un repositorio SHA-1 esa línea devuelve un identificador de 40 caracteres hexadecimales. En uno SHA-256, como el que acabás de crear, el resultado tiene 64 caracteres: el doble de longitud, aunque el contenido hasheado sea exactamente el mismo.

sequenceDiagram
    participant U as Usuario
    participant G as Git
    participant O as Object Database
    U->>G: git hash-object --stdin -w
    G->>G: calcula el hash segun el object-format del repositorio
    G->>O: guarda el objeto blob
    O-->>G: confirma la escritura
    G-->>U: devuelve el hash, 40 o 64 caracteres hex

⚠️ Ojo: un repositorio SHA-256 funciona perfecto en tu máquina, pero hoy es una isla: no podés clonarlo ni empujarlo a GitHub, GitLab ni a la mayoría de los forges que uses en el trabajo diario.

Cómo empezar: probar un repositorio SHA-256 paso a paso

Hace falta Git 2.29 o más reciente; cualquier distribución Linux mantenida en 2026 ya lo cumple. Confirmá tu versión antes de seguir:

git --version

Si el resultado es menor a 2.29, actualizá el paquete git con el gestor de tu distribución Linux antes de continuar (en macOS, brew upgrade git; en Windows, descargá el instalador desde git-scm.com).

1. Creá el repositorio con el formato nuevo: git init --object-format=sha256 demo-sha256.
2. Entrá a la carpeta y confirmá el algoritmo activo: cd demo-sha256 && git rev-parse --show-object-format. Debe imprimir sha256.
3. Agregá un archivo y hacé el primer commit como en cualquier repositorio: echo "demo" > archivo.txt && git add archivo.txt && git commit -m "primer commit SHA-256".
4. Inspeccioná el hash del commit recién creado con git log --format=%H -1: va a mostrar 64 caracteres hexadecimales en lugar de los 40 habituales.

Lo que no vas a poder hacer todavía, al menos con la mayoría de los servicios de hosting disponibles en 2026, es empujar ese repositorio a un remoto en GitHub o GitLab: ninguno de los dos acepta hoy el formato de objeto SHA-256 en sus repositorios alojados.

💡 Tip: si necesitás precisión extra, git rev-parse --show-object-format=storage indica el formato en el que se guardan los objetos en disco, distinto del formato de entrada o salida que puede usar un comando puntual.

Casos de uso reales para el formato SHA-256

Por ahora, el formato SHA-256 tiene sentido en escenarios específicos, no como reemplazo general del flujo diario.

• Equipos de seguridad que necesitan evaluar, antes de cualquier migración corporativa, cómo se comporta su tooling interno (hooks, CI, scripts de automatización) frente a hashes de 64 caracteres.
• Contribuidores del propio proyecto Git que prueban y reportan bugs sobre la tabla de traducción y el soporte de protocolo documentado en hash-function-transition.
• Entornos con cumplimiento regulatorio estricto, donde una política interna exige evitar SHA-1 en cualquier sistema, incluido el control de versiones, más allá de si hay un ataque práctico demostrado contra Git en particular.
• Mantenedores de forges self-hosted (Gitea, Forgejo, servidores Git puros sobre SSH) que pueden alojar repositorios SHA-256 sin depender de que GitHub o GitLab sumen soporte primero.

Errores comunes al probar el formato SHA-256

El error más frecuente es asumir que basta con correr git init --object-format=sha256 en un repositorio que ya existe. Ese comando solo sirve para repositorios nuevos y vacíos: no convierte un historial SHA-1 existente, porque cambiar el algoritmo de hash cambia el identificador de cada objeto, y eso rompe la cadena de integridad que Git construyó commit a commit.

El segundo error es dar por hecho que un proveedor de hosting va a aceptar el push sin avisar nada. En la práctica, el intento falla de inmediato o el servicio ni siquiera ofrece la opción de crear un repositorio remoto en ese formato.

El tercer error es mezclar submódulos de distintos formatos sin verificar antes. Un superproyecto SHA-256 que referencia un submódulo SHA-1, o viceversa, no tiene hoy un camino oficial soportado de punta a punta. Conviene mantener todo el árbol de submódulos en el mismo formato mientras el ecosistema termina de madurar.

Como buena práctica, evaluá el impacto técnico en un repositorio de prueba desechable, nunca en la copia de un proyecto productivo, y documentá qué herramientas de tu pipeline (linters, hooks de pre-commit, integraciones de CI) asumen hashes de 40 caracteres en algún lugar del código.

Comparativa: SHA-1 frente a SHA-256

Profundizando: el plan oficial de transición de hash

El documento hash-function-transition no describe un simple cambio de algoritmo: describe un período de coexistencia. La idea de fondo es que un repositorio pueda almacenar objetos con su hash nativo (SHA-1 o SHA-256) y, al mismo tiempo, mantener una tabla que traduce cada identificador al otro formato, para que herramientas y protocolos que todavía esperan SHA-1 sigan funcionando mientras el ecosistema migra.

Esa tabla de traducción es distinta de una simple reescritura de historial. Reescribir el historial con algo como git filter-repo genera commits nuevos, con padres nuevos y hashes nuevos, y eso cambia la identidad de cada commit. La tabla de traducción, en cambio, busca que el mismo commit lógico tenga dos identificadores válidos y equivalentes, uno por formato, sin que su contenido ni su posición en el historial cambien.

flowchart LR
    A["Commit, hash SHA-1 de 40 hex"] --> T["Tabla de traduccion"]
    B["Commit, hash SHA-256 de 64 hex"] --> T
    T --> C["Mapeo bidireccional por objeto"]
    subgraph Diseno de interoperabilidad
    T
    C
    end

El repositorio también usa el campo extensions.objectFormat para marcar la versión de formato del repositorio como 1 en lugar de 0, una decisión deliberada. Así, versiones antiguas de Git que no entienden SHA-256 rechazan el repositorio en vez de corromperlo silenciosamente. La compatibilidad hacia atrás, en este diseño, se resuelve fallando rápido y con un mensaje claro en vez de corromper datos en silencio.

Otro detalle que documenta el propio proyecto es que la firma de commits y tags con GPG necesita coherencia de formato: un commit SHA-256 firmado incluye ese hash de 64 caracteres dentro del objeto firmado, así que herramientas externas que parsean firmas, por ejemplo para verificar en un pipeline de CI, deben actualizarse para aceptar la longitud nueva antes de poder validar ese tipo de commit.

El impacto no se limita al propio Git. Cualquier herramienta que haya asumido, directa o indirectamente, que un hash de Git siempre tiene 40 caracteres (scripts de CI, parsers de logs, integraciones de terceros, hooks personalizados) necesita una revisión antes de que SHA-256 deje de ser una opción marginal. Esa es, en el fondo, la preocupación técnica real detrás de la crítica de GitButler. El costo de adaptación recae sobre miles de proyectos que nunca pidieron el cambio, aunque SHA-256 en sí sea una elección criptográfica sólida.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: cloná un repositorio de prueba vacío, corré git init --object-format=sha256 y compará con tus propios ojos el largo del hash de un commit contra el de un repositorio SHA-1 cualquiera.

Preguntas frecuentes

¿Puedo migrar un repositorio SHA-1 existente a SHA-256 en Git sin perder el historial?

No de forma directa. Git todavía no incluye una herramienta estable que convierta un repositorio SHA-1 a SHA-256 preservando los hashes originales de cada commit. El plan oficial para lograrlo, basado en una tabla de traducción, sigue documentado como diseño más que como función lista para producción en todos los flujos.

¿GitHub o GitLab aceptan repositorios con el algoritmo SHA-256?

No, al menos no en 2026. Ninguno de los dos servicios ofrece hoy la opción de alojar un repositorio con extensions.objectFormat = sha256, lo que limita el uso práctico de este formato a repositorios locales o alojados en forges self-hosted.

¿Qué le pasa a un submódulo de Git si su formato de hash es distinto al del superproyecto?

No hay un camino oficial soportado para mezclar formatos entre un superproyecto y sus submódulos. La recomendación práctica es mantener todo el árbol de submódulos en el mismo algoritmo mientras el soporte de interoperabilidad siga incompleto.

¿Cuándo pasará SHA-256 a ser el formato de hash por defecto en Git?

La propia comunidad de Git discute el calendario. El post de GitButler que motiva esta nota afirma que el cambio está planeado para una futura versión 3.0, pero esa fecha depende de que la interoperabilidad con los principales servicios de hosting avance primero.

¿Cómo confirmo si un repositorio local usa SHA-1 o SHA-256?

Corré git rev-parse --show-object-format dentro del repositorio. La salida es una sola palabra, sha1 o sha256, sin ambigüedad.

¿El algoritmo SHA-256 hace que verificar commits firmados sea más lento?

No de forma perceptible para un desarrollador individual. El costo adicional de calcular y verificar un hash SHA-256 en vez de SHA-1 es mínimo en hardware moderno. El cuello de botella real hoy es la falta de soporte en herramientas externas, no el rendimiento del algoritmo.

Referencias

• Git 3.0’s upcoming SHA-256 default will be a costly mistake: la crítica de Scott Chacon (GitButler) que motiva esta nota.
• hash-function-transition, documentación técnica oficial de Git: el plan de transición de SHA-1 a SHA-256, con la tabla de traducción y el diseño de interoperabilidad.
• git-init, documentación oficial: detalla la opción --object-format para crear repositorios con un algoritmo de hash específico.
• git-hash-object, documentación oficial: describe cómo Git calcula el identificador de cada objeto según el formato activo del repositorio.
• SHAttered: la investigación de Google y CWI Amsterdam que publicó la primera colisión práctica de SHA-1 en 2017.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Rahul Mishra en Unsplash