Carla abre una incidencia con un título incómodo: "El botón de borrar tarea no borra nada". Lo reproduce en tres navegadores. Pulsas la papelera, la tarea parpadea y sigue ahí.

Lo desconcertante es que funcionaba. En la versión v1.0.0, que el equipo etiquetó hace dos meses (lección 05-05), el borrado funcionaba perfectamente: hay una demo grabada que lo demuestra. Entre aquella etiqueta y main hay 214 commits.

Las opciones evidentes son malas. Leerse los 214 diffs es un día de trabajo y una garantía de no ver nada. Buscar por palabras clave con git log -S "borrar" (lección 02-06) da veintitantos candidatos, y ninguno parece culpable. Y preguntar en el chat del equipo solo produce teorías.

Pero hay una propiedad del problema que lo cambia todo: el historial está ordenado, y en algún punto de esa secuencia el comportamiento pasó de "funciona" a "no funciona". Eso es exactamente el escenario de una búsqueda binaria, y Git trae una implementación integrada: git bisect. Con ella, esos 214 commits se reducen a ocho pruebas.

1. La idea: búsqueda binaria sobre el historial
2. Cuántos pasos hacen falta de verdad
3. Una sesión manual completa
4. git bisect skip: commits que no se pueden probar
5. git bisect log y replay: no perder el trabajo
6. Automatizar con git bisect run
7. El script de prueba para gestor-tareas
8. Los códigos de salida, con detalle
9. --first-parent: saltarse el interior de las fusiones
10. git bisect terms: cuando no es "bueno/malo"
11. Qué hace que un historial sea bisecable

La premisa de bisect es una sola:

Existe un commit concreto a partir del cual el comportamiento cambió. Antes de él, bien; desde él, mal.

Si eso se cumple, no hace falta probar los commits uno a uno. Basta con probar el del medio:

• Si el del medio está mal, el culpable está en la primera mitad. La segunda mitad se descarta entera.
• Si el del medio está bien, el culpable está en la segunda mitad. La primera se descarta entera.

Y se repite sobre la mitad que queda. Cada prueba elimina la mitad de los candidatos.

Git hace todo el trabajo de logística: calcula qué commit probar, hace el checkout por ti (en detached HEAD, lección 03-02), lleva la cuenta de los descartados y al final te dice el hash exacto. Tú solo respondes una pregunta binaria en cada paso: ¿funciona o no?

El número de pruebas es el logaritmo en base 2 del número de candidatos, redondeado hacia arriba. La diferencia con la búsqueda lineal es brutal y merece verse en una tabla:

Ese es el titular: duplicar el tamaño del historial añade una sola prueba. Un repositorio con un millón de commits se biseca en veinte pasos. Es la razón por la que bisect sigue siendo útil por muy grande que sea el proyecto.

El propio Git te lo dice al empezar:

"106 revisiones por probar, aproximadamente 7 pasos". No es una estimación optimista: es matemática.

Carla empieza. Lo primero, dejar el árbol de trabajo limpio: bisect va a hacer muchos checkout, y no puede si hay cambios sin confirmar. Si los tiene, git stash (lección 05-04).

Paso 1: iniciar la sesión.

No responde nada. Git ha entrado en modo bisección: ha creado referencias internas en .git/refs/bisect/ y un fichero .git/BISECT_LOG.

Paso 2: marcar los dos extremos.

Fíjate en lo que ha pasado: Git ha hecho checkout del commit intermedio. El árbol de trabajo de Carla es ahora el del commit 9f3c7a1, y HEAD está desacoplado:

Paso 3: el bucle. Carla abre index.html en el navegador, crea una tarea, pulsa la papelera:

Funciona. Lo marca:

De 106 a 53 de un golpe. Y así sucesivamente:

Carla continúa: good, bad, good, bad... Cinco pruebas más tarde:

Ocho pruebas. 214 commits. Un culpable con nombre, fecha y diff.

Paso 4: mirar el diff.

Ahí está. Bruno cambió los escuchadores individuales por delegación de eventos en el contenedor, que es una mejora legítima. Pero el botón de borrar contiene un <svg> con el icono de papelera, así que al pulsar, e.target es el <svg>, no el botón: classList.contains('borrar') da false y no pasa nada. Con e.target.closest('.borrar') funcionaría.

Sin bisect, encontrar eso habría llevado horas. Con él, ocho pruebas y un diff de doce líneas.

Paso 5: salir. Y este paso no es opcional:

reset limpia el estado de bisección y devuelve a HEAD a donde estaba al empezar. Si lo olvidas, te quedas en detached HEAD sobre un commit antiguo, y el siguiente git status será una sorpresa desagradable.

Resumen de los comandos de la sesión:

El atajo del inicio ahorra dos comandos y es el que se usa en la práctica:

En la sexta prueba, Carla se encuentra esto:

Ese commit está roto por otro motivo. No es que el borrado no funcione: es que la aplicación entera no arranca. Marcarlo bad sería mentirle a bisect y podría llevarlo por el camino equivocado; marcarlo good, peor todavía.

La respuesta correcta es:

skip le dice a Git: "este commit no me da información". Git elige otro candidato cercano y sigue. Si acabas saltándote demasiados y no puede aislar uno solo, te lo dirá:

En ese caso te da un conjunto pequeño de sospechosos, que ya es infinitamente mejor que 214.

También se pueden saltar rangos enteros, si sabes que toda una zona no compila:

Motivos habituales para skip: el commit no compila, faltan dependencias que aún no estaban en el package.json, o el commit es de un cambio de formato masivo que hace imposible ejecutar nada. skip es tu amigo; mentir a bisect no.

A mitad de una bisección larga puede pasar de todo: te equivocas al marcar, se cierra el terminal, o tienes que atender otra cosa. git bisect log guarda la sesión:

Guardarlo y recuperarlo después:

replay reconstruye la sesión hasta donde llegaste y te deja en el siguiente commit por probar.

Y aquí está su otro uso, el más valioso: corregir un error de marcado. Si te das cuenta de que dijiste good donde debías decir bad, no hay que empezar de cero:

La sesión manual funciona, pero ocho vueltas de "abrir el navegador, crear una tarea, pulsar, marcar" son ocho oportunidades de equivocarse y veinte minutos de la vida de Carla.

Si la comprobación se puede escribir como un comando que devuelve 0 cuando está bien y algo distinto de 0 cuando está mal, git bisect run lo hace todo solo:

Git prueba, ejecuta el comando, interpreta el código de salida, marca, avanza y repite hasta encontrar el culpable. Sin intervención humana.

Con una batería de pruebas, es literalmente esto:

Y para un solo caso, puede bastar un comando de una línea:

grep -q devuelve 0 si encuentra, 1 si no. Es exactamente el contrato que bisect run espera.

Como el fallo de Carla es de comportamiento en el navegador, hace falta un script algo más elaborado. El equipo tiene una prueba automatizada con Node:

Y la prueba en sí, que simula el DOM mínimo necesario:

Los tres puntos que hacen que este script funcione bien con bisect:

1. Prueba una sola cosa. Solo el borrado. Si la prueba fallara también por otros motivos, bisect encontraría el primer commit que rompe cualquier cosa, que no es lo que buscamos.
2. Distingue "no funciona" de "no se puede evaluar". Ese es el papel del 125, y es lo que veremos ahora.
3. Es silencioso y determinista. Sin salida interactiva, sin depender de la red, sin fallos intermitentes. Una prueba que a veces falla envenena toda la bisección.

Lanzándolo:

Cuarenta segundos, sin tocar el teclado. Y una advertencia sobre el #!: el script debe ser ejecutable (chmod +x) y estar fuera del árbol de trabajo o presente en todos los commits. Si vive dentro del repositorio y en los commits antiguos no existía, bisect no lo encontrará al hacer checkout de esos commits. La solución habitual es copiarlo a /tmp y ejecutarlo desde allí:

Este es el contrato completo de git bisect run, y conocerlo es la diferencia entre una automatización que funciona y una que da resultados falsos:

Tres consecuencias prácticas:

• 125 es la pieza clave. Es el equivalente automático de git bisect skip. Sin él, un commit que no compila se marcaría como "malo" y bisect te señalaría un culpable equivocado.
• 126 y 127 son trampas mortales. Si el script no es ejecutable o la ruta está mal, bisect marcará todos los commits como malos y "encontrará" como culpable el primero del rango. Si el resultado te parece absurdo, comprueba primero que el script se ejecuta a mano: ./mi-script.sh; echo $?.
• Evita exit 128 y superiores. Un kill -9 de un proceso da 137, por ejemplo. Si tu script puede terminar así, envuélvelo para normalizar el código de salida.

Comprobación previa obligatoria, siempre, antes de lanzar un bisect run:

Treinta segundos que evitan biseccionar durante diez minutos hacia una respuesta inventada.

El historial de gestor-tareas tiene fusiones (lección 03-03), y bisect por defecto explora todos los commits alcanzables, incluidos los internos de cada rama fusionada. Eso tiene dos inconvenientes:

• Los commits intermedios de una rama en desarrollo suelen estar a medias: puede que ni compilen, y acabas haciendo muchos skip.
• A efectos de main, lo que importa es en qué fusión entró el problema, no cuál de los seis commits de la rama lo introdujo.

Con --first-parent, Git solo considera la línea principal: los commits directos de main y los commits de fusión, sin entrar dentro de las ramas. Es exactamente el mismo concepto de --first-parent que veremos en git log en la lección 06-04, y el mismo "primer padre" que elegía -m 1 al revertir una fusión (lección 05-06).

Sin --first-parent, los candidatos son a1, f1, f2, f3, a2, M1, a3. Con --first-parent, solo a1, a2, M1, a3.

Cuándo usar cada uno:

La táctica de dos fases es la mejor de las dos: primero --first-parent para identificar la fusión, después una segunda bisección dentro de esa rama:

M1^2 es el segundo padre (la punta de la rama fusionada) y M1^1 el primero (la base en main), con la notación de la lección 02-06.

bisect no es solo para buscar regresiones. Sirve para localizar cualquier cambio de estado monótono en el historial. Los ejemplos típicos:

• ¿En qué commit se arregló un fallo? (aquí "bueno" y "malo" están invertidos)
• ¿En qué commit el arranque pasó de tardar 200 ms a 900 ms?
• ¿En qué commit el paquete pasó de 400 KB a 1,2 MB?

En esos casos, la terminología por defecto confunde. git bisect terms permite renombrarla:

A partir de ahí, en cada paso respondes git bisect roto o git bisect arreglado, y Git busca el primer commit arreglado.

Lo que hay que entender es que a Git le dan igual las palabras: siempre busca el primer commit con el estado "nuevo", sea "roto", "arreglado", "lento" o "gordo". Consultar los términos activos en cualquier momento:

Un ejemplo de rendimiento, midiendo con el propio script:

La última línea del script es la que decide: [ "$bytes" -lt 512000 ] devuelve 0 si se cumple y 1 si no, que es justo el contrato de bisect run.

bisect es una herramienta que te devuelve lo que le diste. Su eficacia depende directamente de la calidad del historial, y ahí es donde el módulo 5 y este se dan la mano:

Dicho de otro modo: el rebase interactivo de la lección 05-02 no es cosmética. Cuando consolidas los fixup!, divides un commit gigante y te aseguras de que cada uno deja el proyecto en un estado funcional, lo que estás construyendo es un historial bisecable. La factura de no hacerlo se paga el día en que hay que encontrar una regresión de hace dos meses.

Y con --exec (lección 05-02) puedes comprobar por adelantado que toda una rama es bisecable antes de integrarla:

Git aplica cada commit y ejecuta la comprobación en cada uno. Si alguno falla, te detiene ahí.

Todo esto —commits atómicos, historial que compila, qué consolidar antes de integrar— es el tema de la lección 08-02: Manteniendo un Historial Limpio. bisect es la mejor justificación práctica que existe para esas prácticas: convierte una virtud abstracta en minutos de trabajo ahorrados.

Una última nota de alcance: bisect responde a "¿qué commit cambió este comportamiento?". No responde a "¿por qué mi repositorio está en un estado extraño?" ni "¿qué está haciendo Git por debajo?". Ese diagnóstico —reflog, fsck, GIT_TRACE y compañía— es el terreno de las lecciones del módulo 9, y en particular de la 09-06: Técnicas Avanzadas de Depuración.

Error 1: empezar con el árbol de trabajo sucio. bisect hace checkout en cada paso y fallará o arrastrará tus cambios entre commits. Confirma o haz git stash antes.

Error 2: olvidar git bisect reset. Te quedas en detached HEAD sobre un commit de junio. Todo commit que hagas ahí quedará huérfano.

Error 3: invertir good y bad al empezar. El orden del atajo es git bisect start <MALO> <BUENO>. Si lo inviertes, Git buscará en el sentido contrario y no encontrará nada coherente.

Error 4: marcar bad un commit que está roto por otro motivo. Usa skip. Mentirle a bisect produce un culpable equivocado con toda la apariencia de ser correcto.

Error 5: olvidar el exit 125 en el script. Sin él, los commits que no compilan cuentan como malos y el resultado es basura.

Error 6: un script no ejecutable o con la ruta mal. Códigos 126/127: todo sale "malo" y el culpable es el primer commit del rango. Prueba el script a mano antes.

Error 7: dejar el script dentro del repositorio. En los commits antiguos puede no existir. Cópialo a /tmp y ejecútalo desde fuera.

Error 8: una prueba no determinista. Si falla una de cada cinco veces, bisect te dará una respuesta distinta cada vez. Asegura el determinismo antes de automatizar.

Consejo 1: elige el "bueno" más reciente que puedas. Empezar en v1.0.0 en lugar de en el primer commit del proyecto ahorra pasos. Las etiquetas (lección 05-05) son perfectas para esto.

Consejo 2: guarda siempre git bisect log. Una sesión larga es trabajo valioso. Un fichero de texto te permite retomarla o corregir un marcado erróneo.

Consejo 3: primero --first-parent, después dentro de la rama. Rápido para localizar la fusión, preciso para localizar el commit.

Consejo 4: bisect run con npm test es a menudo suficiente. Si ya tienes pruebas, no escribas nada nuevo.

Consejo 5: cuando encuentres el culpable, no lo revientes sin más. Míralo, entiéndelo y decide: git revert si está publicado (lección 05-06), o una corrección hacia delante si el cambio en sí era bueno y solo faltaba un detalle —como en el caso de Bruno, donde la delegación de eventos era correcta y solo faltaba closest().

Crea un repositorio con 15 commits donde el fichero valor.txt contiene 10, y a partir del commit número 9 pasa a contener 99 (el "fallo"). Después:

1. Inicia una bisección con main como malo y el primer commit como bueno.
2. En cada paso, comprueba cat valor.txt y marca good o bad.
3. Comprueba que Git identifica exactamente el commit 9.
4. ¿Cuántos pasos has necesitado? ¿Coincide con log₂(14)?

Con el mismo repositorio del ejercicio 1:

1. Escribe un script en /tmp que devuelva 0 si valor.txt contiene 10 y 1 si no.
2. Prueba el script a mano en un commit bueno y en uno malo antes de usarlo.
3. Lanza git bisect run y comprueba que encuentra el mismo commit.
4. Añade al repositorio un commit intermedio en el que valor.txt no exista, y haz que el script devuelva 125 en ese caso. Comprueba que la bisección sigue funcionando.

Crea un repositorio de 10 commits donde estado.txt contiene roto y a partir del commit 7 pasa a contener arreglado. Usando --term-old y --term-new, encuentra el primer commit arreglado. Escribe también el bisect run correspondiente.

Solución 1:

Cuatro pruebas para 14 candidatos. log₂(14) ≈ 3,8, que redondeado hacia arriba son 4. Exacto.

Solución 2:

Comprobación previa, que nunca hay que saltarse:

El commit no evaluable:

Cuando la bisección llega al commit sin valor.txt, el script devuelve 125 y Git lo salta:

El culpable sigue siendo el commit 9: el 125 ha evitado que un commit inevaluable falseara el resultado.

Solución 3:

Con automatización:

Lo importante: aunque los términos se llamen roto y arreglado, el script sigue devolviendo 0 para el estado antiguo y 1 para el nuevo. bisect no interpreta las palabras; solo busca la frontera.

git bisect convierte una búsqueda desesperada en un procedimiento mecánico y acotado. Lo esencial:

• Es una búsqueda binaria sobre el historial: cada prueba descarta la mitad de los candidatos, así que hacen falta log₂(n) pruebas. 214 commits son 8 pruebas; un millón, veinte.
• La sesión manual es start → bad → good → bucle de pruebas → reset. El reset final no es opcional: sin él te quedas en detached HEAD.
• git bisect skip es la respuesta honesta a un commit que no se puede evaluar. Mentir marcando good o bad produce un culpable falso.
• git bisect log y replay salvan sesiones largas y permiten corregir un marcado erróneo sin empezar de cero.
• git bisect run <comando> automatiza todo el proceso. El contrato son los códigos de salida: 0 bueno, 1–124 malo, 125 saltar, 128+ abortar. El 125 es lo que separa una automatización fiable de una que inventa respuestas.
• Prueba siempre el script a mano en un commit bueno y en uno malo antes de lanzar bisect run, y sácalo del árbol de trabajo (/tmp) para que exista en todos los commits.
• --first-parent limita la búsqueda a la línea principal: menos ruido y menos skip. La táctica de dos fases —primero la fusión, después dentro de la rama— combina velocidad y precisión.
• git bisect terms generaliza la herramienta a cualquier cambio de estado monótono: cuándo se arregló algo, cuándo empezó a ir lento, cuándo engordó el paquete.
• Y la conclusión de fondo: un historial de commits pequeños que compilan es un historial bisecable. La lección 08-02 lo desarrolla; bisect es la razón por la que importa.

Carla ya tiene el commit culpable y el diff exacto. Pero al mirar app.js para arreglarlo se encuentra otra cosa: veinte líneas más abajo hay una función de normalización de texto que nadie sabe para qué está, con un replace de caracteres raros que parece arbitrario. Nadie del equipo recuerda haberla escrito. Borrarla parece tentador... y probablemente rompería algo.

Antes de tocar código que no entiendes, hay que saber quién escribió cada línea, cuándo y en qué commit, para poder leer el mensaje que explica el porqué. Esa es la herramienta de la lección 06-03: Git Blame.