Git 2.56 añade history drop y delete-merged

Git 2.56 está en forma de candidata a versión y se espera para finales de septiembre de 2026. LWN.net informó de que la versión lleva más de 700 commits que no son fusiones. La mayoría son fontanería. Pero un puñado de órdenes nuevas cambia lo que un desarrollador puede hacer sin recurrir a un rebase interactivo.

LWN llama a la 2.56 "una versión sólida" y dice que el proyecto está "guardando buena parte de su trabajo más importante para el futuro". Ese futuro es Git 3.0.

Las órdenes nuevas

Orden u opción	Qué hace
git history drop	Quita de una rama los commits indicados repitiendo los que vienen después
git repo info	Imprime las rutas del repositorio, absolutas y relativas
git add --resolved	Prepara solo las rutas de fusión cuyos conflictos ha resuelto
git branch --delete-merged	Borra ramas locales ya fusionadas en su rama de seguimiento remota
git bisect --reset-when-found	Restaura el estado original en cuanto bisect encuentra el commit
git replay --linearize	Descarta commits de fusión mientras repite el historial
git refs	Crea, borra, actualiza y renombra referencias directamente

Qué hace history drop, y dónde se detiene

git history drop quita de una rama un commit que usted indica. Funciona repitiendo cada commit que vino después. Ese es el trabajo que hoy se hace con un rebase interactivo, escrito con cuidado, línea a línea.

Conviene conocer un límite antes de contar con ello. Las notas de versión de Git dicen que la orden sigue negándose a funcionar si el historial contiene commits de fusión. Muchas ramas reales los contienen. La orden encaja más con una rama de función lineal que con una rama compartida de larga vida.

git replay --linearize llega al mismo terreno por el otro lado. Descarta commits de fusión mientras repite, lo que aplana un historial enredado hasta dejarlo en línea recta.

Cambios menores que sí notará

git add --resolved apunta a un lío habitual en mitad de una fusión. Durante un conflicto es frecuente arreglar dos archivos y dejar otras ediciones en el árbol de trabajo. La opción nueva prepara solo las rutas cuyos conflictos ha resuelto, y deja en paz el resto de sus cambios locales.

git branch --delete-merged limpia las ramas locales que ya se fusionaron en la rama a la que siguen. Git también imprime un mensaje más claro cuando una de esas ramas se está usando para una bisección.

Las notas de versión del proyecto Git enumeran varios arreglos más discretos. Git ahora detecta erratas en órdenes como git push origin/main. Un nuevo ajuste fetch.followRemoteHEAD controla cómo trata un fetch la rama por defecto del remoto. Pedir ayuda a cualquier orden termina ahora con código 0 en lugar de 129, lo que evita que un script lea una petición de ayuda como un fallo. Las órdenes de configuración reintentan cuando chocan, lo que reduce los errores de bloqueo si dos órdenes escriben a la vez.

Por debajo, git cat-file --batch formatea la salida más rápido, y git log --follow maneja mejor que antes un historial no lineal.

Qué significa esto para los desarrolladores

Pruebe git history drop sobre una copia de una rama antes de confiárselo a una real. La restricción de los commits de fusión decide si encaja en su forma de trabajar. Ejecute git log --merges sobre el rango que quiere editar: si imprime algo, la orden se negará.

git branch --delete-merged es la que conviene volver costumbre. La mayoría de los desarrolladores acumulan decenas de ramas locales muertas y las limpian con una tubería de shell copiada de un blog hace años. Una opción integrada es más segura, porque comprueba la rama de seguimiento remota en vez de comparar nombres.

El cambio de código de salida merece una revisión de sus propias herramientas. Cualquier script que tratara el 129 como la señal de una petición de ayuda verá ahora un 0. Ese es el comportamiento correcto, pero es un cambio de comportamiento, y fallará en silencio en vez de a gritos.

Nada de esto rompe un repositorio existente. Los cambios que sí lo harán están en la versión siguiente: Git 3.0 pasa los repositorios nuevos a SHA-256 y reftable, y hace de Rust una dependencia obligatoria de compilación. El documento de cambios incompatibles de Git sigue sin dar fecha para la 3.0. Tome la 2.56 como la última parada tranquila antes de esa.