Cuando te encuentres un bug en tu programa y te preguntes desde cuándo está ahí, podrás usar el comando git-bisect para encontrar el commit en el que se introduce ese bug.
Para poder hacer esto, necesitarás que se cumpla lo siguiente:
- El bug no debería ser intermitente, es decir, se introduce a partir de un momento de tiempo, pero no aparece y desaparece (eso podría hacer que la búsqueda sea dificil).
- Debes tener identificado un momento del historial de tu repositorio en el que no haya bug. Por ejemplo, tal vez sepas que hace 1 mes no fallaba.
Vamos a imaginar el siguiente supuesto. Tengo un repositorio cargado de commits. Ahora mismo, en HEAD, hay un script que está fallando. Sin embargo, sé que en mi último despliegue a producción, ese script funcionaba bien. Por suerte tengo un tag para etiquetarlo, aunque también podrías trabajar manualmente con el hash de ese commit. Lo importante es que lo localices.
81ce695 (HEAD -> trunk) Reescribir comentarios para clarificar la intención
e09abff Añadir soporte para la nueva funcionalidad Z
efe7c51 Reescribir comentarios para clarificar la intención
365c2d7 Corregir patrón de expresión regular incorrecto
75dfb7f Mejorar los registros para el modo de depuración
f2a3d6b Corregir problemas de formato en la salida JSON
3ee0e21 Actualizar API para usar la versión 2
221d9f4 Actualizar README con pasos de instalación
9fe8160 Añadir archivo de configuración de ejemplo
21b336d (tag: prod-20241230) Añadir comprobaciones para valores nulos
Ahora empiezo con git bisect start para decirle a Git que quiero empezar a buscar bugs. Empezaré por el commit en el que estoy ahora mismo, que será el más reciente.
Ejecuto mi comando, mis tests, o lo que sea que use para ver si el bug está ahí o no. Como ese bug está ahí, lo que hago es usar el comando git bisect bad para decírselo.
Ahora me tengo que ir a un momento del tiempo en el que mi programa funcionaba bien. Por ejemplo, el commit que tenía tagueado. Podría hacer un cambio por ese commit y ver que los tests pasan...
git checkout prod-20241230
./run-tests
Y cuando encuentre que el commit funcionaba bien, se lo marco con el comando git bisect good.
Ahora que Git tiene un commit en el que el programa iba bien y un commit en el que iba mal, va a empezar una búsqueda binaria. Es decir, empezará a ofrecerme commits, uno tras otro. Yo debo correr los tests o lanzar el programa en los commits que me ofrezca, para ver si el bug está en esa rama o no.
Si en el commit que me ha entregado hay bugs, se lo diré con git bisect bad. Si ese commit funciona bien, se lo diré con git bisect good. A medida que se lo vaya diciendo, lo que hará Git es ir recortando por cada lado del historial más o menos commits. Eventualmente, llegará al candidato y nos lo mostrará por terminal.
A partir de ahí, podemos encontrar a qué pull request o en general tarea la pertenece, para poder ver qué hacer con él, si revertirlo, corregirlo, o lo que sea que se nos ocurra.
Recuerda usar git bisect reset cuando hayas terminado para dejar el repositorio como estaba, porque git bisect te mueve el working directory al pasado a medida que te va cambiando commit a commit.