Git 2.56.0 llega con merge-base más rápido y repacks más pequeños

Git 2.56.0 ya está disponible. Junio C Hamano, que mantiene Git, anunció la versión el 28 de septiembre de 2026. La mayoría de las mejoras tienen que ver con la velocidad y el espacio en disco. Una consulta de merge-base en el kernel de Linux ahora requiere 3.887 pasos en lugar de 167.441. Una nueva forma de empaquetar repositorios redujo un 71 % un gran repositorio de prueba.

La versión incluye 748 commits que no son fusiones desde que Git 2.55 salió en junio, según el anuncio de Hamano. Proceden de 104 desarrolladores, y 39 de ellos contribuyeron a Git por primera vez.

Tech AI Wire adelantó las nuevas órdenes de la candidata a versión la semana pasada, entre ellas git history drop y git branch --delete-merged. Este artículo cubre lo que añaden a eso las notas de la versión final, GitHub y GitLab.

Merge-base es hasta 70 veces más rápido

Una base de fusión (merge base) es el commit más reciente que comparten dos ramas. Git la calcula cada vez que usted fusiona, hace un rebase o pregunta cuánto se ha alejado una rama de main. En un repositorio grande, ese recorrido hacia atrás por el historial puede ser lento.

Git 2.56 detiene el recorrido antes. El anuncio de Hamano dice que Git ahora se detiene "cuando se agotan en la cola los commits exclusivos de uno de los lados". Dicho de forma sencilla, en cuanto Git puede demostrar que una rama no tiene nada más que aportar, deja de buscar.

La publicación de GitHub con los aspectos destacados pone cifras al cambio. Una consulta de merge-base en el kernel de Linux pasó de 167.441 pasos, en 0,29 segundos, a 3.887 pasos, en 0,01 segundos. En dos grandes monorepos, GitHub midió una aceleración de 70 veces en uno y una aceleración media de 20 veces en el otro.

Un cambio relacionado reutiliza respuestas anteriores dentro de órdenes como git branch --contains, que lista las ramas que incluyen un commit determinado. Eso acelera las comprobaciones que hace Git para ver si un commit puede alcanzar a otro.

Repositorios más pequeños con los repacks path-walk

Git guarda el historial en archivos pack, que son paquetes comprimidos de objetos. Un repack reescribe esos paquetes para ahorrar espacio. La opción --path-walk reúne los objetos ruta de archivo por ruta de archivo antes de comprimir, de modo que las versiones de un mismo archivo se comparan entre sí.

En la prueba de GitHub con el repositorio de Fluent UI, el pack se redujo de 558,5 MB a 164,4 MB. Eso es aproximadamente un 71 % menos. En 2.56, los repacks path-walk también funcionan con los bitmaps de alcanzabilidad (reachability bitmaps) y las islas delta (delta islands). Los servidores Git usan esas dos funciones para iniciar clones rápidamente y para mantener separados los forks que comparten almacenamiento.

Los clones parciales pueden volver a deshacerse de archivos grandes

Un clon parcial descarga el historial sin todos los archivos grandes. Obtiene los blobs, la palabra de Git para el contenido de los archivos, solo cuando una orden los necesita. Con el tiempo, esos archivos descargados se acumulan en el disco.

Git 2.56 añade una forma de eliminarlos. El anuncio de la versión dice que git repack con --drop-filtered borra los blobs locales por encima de un límite de tamaño que el servidor todavía puede proporcionar. La publicación de GitHub da un ejemplo completo: git repack -a --filter=blob:limit=1m --drop-filtered. Es un paso manual, no una limpieza automática.

Correcciones de conflictos más seguras y logs más claros

git add --resolved prepara solo los archivos cuyos conflictos de fusión usted arregló. La versión final también revisa esos archivos en busca de marcadores de conflicto sobrantes, las líneas <<<<<<< que Git escribe en un archivo con conflictos. Así es más difícil que un archivo a medio arreglar se cuele en un commit.

git log --follow ahora sigue mejor un archivo a lo largo de un historial con varios renombrados y fusiones. git log --graph sangra los commits raíz, los que no tienen padre, para que las historias separadas destaquen. La opción --no-graph-indent o el ajuste log.graphIndent controlan eso.

Qué viene después de 2.56

La próxima versión no será la 2.57. El ingeniero de GitLab Karthik Nayak escribe que Git planea saltar a la 2.98 en diciembre de 2026. Git 2.99 y Git 3.0 están previstos para la primavera de 2027. "Este salto significativo sirve como indicación, tanto para los mantenedores downstream como para los consumidores, de que se avecina un gran cambio", escribe Nayak.

Ese cambio es el paso de Git 3.0 a SHA-256 y reftable como opciones predeterminadas, además de Rust como parte obligatoria de la compilación.

Qué significa esto para los desarrolladores

La mayoría de los desarrolladores obtienen la aceleración de merge-base con solo actualizar. Importa sobre todo en grandes monorepos y en trabajos de CI que hacen rebase o comparan ramas muchas veces al día. Si su pipeline fija una versión antigua de Git dentro de una imagen de contenedor, esa fijación es lo que se interpone entre usted y la mejora.

Pruebe git add --resolved la próxima vez que una fusión se detenga por conflictos. Sustituye la costumbre de ejecutar git add . a mitad de una fusión, que prepara cada edición suelta del árbol junto con las correcciones.

Si administra un servidor Git o mantiene réplicas grandes, pruebe --path-walk en una copia de un repositorio y compare los tamaños de los pack. El resultado de Fluent UI procede de un solo repositorio, y su combinación de archivos será distinta. Mida antes de cambiar un trabajo de repack en producción.

Por último, prepárese para el salto de versión. Un script que compare la salida de git --version y espere la 2.57 como siguiente se encontrará en su lugar con la 2.98. Revise esas comparaciones ahora, mientras el cambio aún está a meses de distancia.