Buscando commits malos con el Inspector Gadget

Hay una situación que todo desarrollador acaba viviendo al menos una vez. Te vas un viernes a casa contento con el código funcionando, pero al día siguiente, o tres días después, o una semana más tarde, abres el proyecto y algo ya no va. Y lo peor es que no tienes ni idea de cuándo se rompió.

Lo primero que hace uno es revisar los últimos cambios. Ves que en los últimos 10 commits no se ha tocado nada relacionado con lo que falla (genial). Tendré que mirar más commits diría uno. Pero si el repo involucra a varios compañeros, el historial de commits puede ser bastante extenso. Además, un bug que encuentras hoy no tiene por qué haberse introducido hace poco, igual lleva dos meses en el repositorio.

Git bisect y el Inspector Gadget (un grande)

Para eso existe ✨git bisect ✨.

git bisect start [--term-(bad|new)=<term-new> --term-(good|old)=<term-old>]
		   [--no-checkout] [--first-parent] [<bad> [<good>…]] [--] <pathspec>…]
git bisect (bad|new|<term-new>) [<rev>]
git bisect (good|old|<term-old>) [<rev>…]
git bisect terms [--term-(good|old) | --term-(bad|new)]
git bisect skip [(<rev>|<range>)…]
git bisect next
git bisect reset [<commit>]
git bisect (visualize|view)
git bisect replay <logfile>
git bisect log
git bisect run <cmd> [<arg>…]
git bisect help

Posibles usos del comando git bisect.

Uso básico de git bisect

Este comando emplea un algoritmo de búsqueda binaria para dar con el commit exacto que introdujo un bug en tu proyecto. Para utilizarlo, primero se deben especificar: un commit que contenga el bug; y un commit que no.

Con esto, git bisect seleccionará un commit que esté los dos proporcionados, y te preguntará si es bueno o malo. De este modo, el comando continuará la búsqueda acortando el rango de commits hasta dar con aquel que introdujo el bug.

¿Cómo proceder?

$ git bisect start
$ git bisect bad                 # Con HEAD apuntando al commit malo
$ git bisect good v1.2.3         # v1.2.3 sería un commit bueno

Ahora, git bisect selecciona un commit en mitad del rango proporcionado, hace checkout al mismo y muestra un mensaje en consola similar a:

Bisecting: 675 revisions left to test after this (roughly 10 steps)

En este punto, el usuario o desarrollador deberá compilar el commit concreto en el que te ha posicionado git bisect y comprobar si contiene o no el bug. Si dicha revisión es buena, escribiremos git bisect good, y git bisect bad de otro modo.

Este proceso deberá repetirse hasta que no queden commits por revisar y git bisect muestre en consola una descripción acerca del primer bad commit. La referencia refs/bisect/bad apuntará a dicho commit.

"Cómo es posible que esto no compile ahora 😞. ¡Hace TRES meses compilaba!"

Puedes decirle a git bisect que, automáticamente, en cada iteración de la búsqueda ejecute make y compruebe él mismo si falla o no. Esto viene genial si el problema es que tu proyecto antes compilaba y ahora no y no sabes por qué.

$ git bisect start HEAD v1.2 --      # HEAD está roto, v1.2 compilaba
$ git bisect run make                # "make" para compilar
$ git bisect reset                   # Para salir cuando acabe

Usar git bisect para lanzar tests automáticamente

También puede pasar que reproducir el bug sea un rollo porque haya que hacer muchos pasos hasta que suceda; o que sea complicado reproducirlo. Si tus tests están medio bien planteados, puede que te baste con ejecutarlos para ver si el bug está incluido en un commit concreto o no. Esto lo hace git bisect automáticamente:

$ git bisect start HEAD origin --    # HEAD está roto, origin está OK
$ git bisect run make test           # "make test" compila y lanza los tests
$ git bisect reset                   # Para terminar

Hay mucho más en lo que a git bisect respecta, pero creo que con estos dos o tres casos de uso hay de sobra para empezar. Para más detalles recomiendo leer git-scm/git-bisect.