por Cuando un programa funcionaba hace dos semanas y hoy falla, revisar uno por uno todos los commits intermedios es una forma bastante lenta de encontrar al culpable. git bisect va probando puntos de la historia y descarta la mitad de los candidatos en cada paso. Con 100 commits no necesita 100 pruebas: normalmente bastan unas siete.
No arregla el fallo ni adivina qué está mal. Su trabajo es reducir una búsqueda vaga —«antes iba bien»— a un commit concreto que ya podemos leer, probar y revertir si corresponde.
Preparar una prueba que responda sí o no
Antes de iniciar la búsqueda necesitamos dos referencias: un commit actual donde el error exista y otro anterior que sepamos que funciona. También necesitamos una prueba repetible. Puede ser un test automático, una orden que devuelve un resultado o una comprobación manual muy concreta.
Por ejemplo, no sirve demasiado «la aplicación parece rara». Sí sirve «al abrir este archivo aparece el error», «esta URL devuelve 500» o «este test falla». Cuanto menos dependa de nuestra memoria, más fiable será el resultado.
Guardamos o apartamos primero cualquier cambio pendiente, porque Git irá cambiando los archivos de la carpeta de trabajo:
git status
git log --oneline --decorate -n 15
Si tenemos trabajo a medias que no queremos mezclar, podemos hacer la búsqueda en otra carpeta con Git worktree. Así no tocamos el árbol donde seguimos programando.
Marcar el punto malo y el último bueno
Iniciamos la búsqueda y decimos que el commit actual es malo:
git bisect start
git bisect bad HEAD
Después indicamos una versión conocida como buena. Puede ser un hash, una etiqueta o una rama. En este ejemplo usamos la etiqueta v1.4.0:
git bisect good v1.4.0
Git cambia entonces a un commit situado aproximadamente a mitad del recorrido. Ejecutamos nuestra prueba. Si funciona, marcamos ese punto como bueno; si reproduce el fallo, lo marcamos como malo:
git bisect good
o bien:
git bisect bad
Después de cada respuesta, Git elige otro commit y muestra cuántas revisiones quedan por comprobar. Repetimos hasta que indique el primer commit malo. En ese momento conviene leer el cambio y no condenarlo sólo por estar señalado:
git show --stat
git show
El primer commit donde nuestra prueba falla no siempre contiene toda la causa. Quizá activó un error que ya estaba latente, cambió una dependencia o la prueba dependa de datos externos. git bisect aporta un punto de partida pequeño; la explicación todavía la tenemos que confirmar.
Terminar y volver a nuestra rama
Al acabar ejecutamos:
git bisect reset
Esto abandona el modo de búsqueda y devuelve la carpeta al commit o rama donde estábamos antes. No lo dejaría para «luego»: trabajar sin darnos cuenta sobre el commit intermedio de un bisect es una buena forma de confundirse.
Si un punto intermedio ni compila ni permite ejecutar la prueba por un motivo distinto al error investigado, podemos saltarlo:
git bisect skip
No conviene abusar de skip. Si saltamos varios commits cercanos, Git puede terminar con un grupo de posibles culpables en vez de uno solo.
Automatizar la búsqueda con git bisect run
Cuando ya existe una prueba automática, Git puede recorrer la búsqueda por nosotros. Preparamos un script o una orden que devuelva código 0 cuando el commit sea bueno y un código entre 1 y 127 cuando sea malo; el 125 se reserva para indicar que ese commit no se puede probar.
Después de marcar el extremo bueno y el malo, lanzamos por ejemplo:
git bisect run ./prueba.sh
En una prueba local para preparar este artículo construí un repositorio pequeño con ocho commits y un script que comprobaba un cálculo. La búsqueda automática señaló como primer commit malo cambiar multiplicador, que era justo el cambio donde se había introducido el resultado incorrecto. Después git bisect reset devolvió la rama al último commit.
No metería en prueba.sh una orden que modifique bases de datos reales, envíe correos o despliegue el proyecto. git bisect run puede ejecutarla varias veces y sobre código antiguo. Lo ideal es un test aislado, rápido y sin efectos fuera de la carpeta.
Cuando el resultado no es fiable
Hay tres casos que suelen estropear la búsqueda:
- Elegimos como «bueno» un commit que en realidad también tenía el fallo.
- La prueba falla unas veces sí y otras no.
- Los commits antiguos ya no funcionan con el entorno actual, aunque el error buscado no existiera.
En esos casos es mejor parar con git bisect reset, estabilizar la prueba y escoger referencias que hayamos comprobado. También podemos anotar el registro de una sesión con git bisect log y repetirlo más tarde mediante git bisect replay.
La documentación de Git bisect recoge estas opciones y búsquedas más avanzadas. Para la mayoría de errores, recordar start, bad, good y reset ya convierte una tarde revisando commits en una búsqueda bastante corta.
Si lo probáis en un proyecto real, contadnos cuántos commits había entre la versión buena y la mala y cuántas pruebas necesitó Git.
