git-bisect

git-bisect es un comando de diagnóstico muy potente que permite identificar en un log de Git el momento exacto en el que se introduce un bug (o ya puestos, lo que sea que estemos buscando). Podemos iniciar un bisect con `git bisect start`, y luego ir etiquetando commits con el sub-sub-comando "good" como "buenos", o con el sub-sub-comando "bad" como malos.

Cuando nos enfrentamos a un bug en nuestro código y no sabemos exactamente en qué momento se introdujo, el comando git bisect se convierte en una herramienta imprescindible para localizar el commit problemático de forma rápida y eficiente. Este comando nos permite hacer una búsqueda binaria entre los commits de nuestro repositorio para identificar el punto exacto en el que el error apareció.

Imaginemos que tenemos un historial de commits donde sabemos que en un momento pasado el código funcionaba correctamente, pero en el commit actual el programa falla. Lo que necesitamos es encontrar ese commit específico que introdujo el bug. Para ello, git bisect nos guía preguntándonos si un commit determinado es bueno o malo, es decir, si el código funciona o no en ese punto. Nosotros respondemos con git bisect good o git bisect bad, y el comando descarta automáticamente los commits que no pueden ser el origen del problema, hasta que finalmente nos señala el commit culpable.

Para empezar a usar git bisect, primero iniciamos la sesión con:

git bisect start

Luego, marcamos el commit actual, donde sabemos que el bug está presente, como malo:

git bisect bad

Después, indicamos un commit anterior donde el código funcionaba bien, usando su hash o etiqueta:

git bisect good <hash_del_commit_bueno>

A partir de aquí, Git selecciona un commit intermedio para que lo probemos. Ejecutamos nuestro programa o pruebas para verificar si ese commit es bueno o malo. Por ejemplo, si el programa falla, indicamos:

git bisect bad

Si funciona correctamente, usamos:

git bisect good

Este proceso se repite, con Git eligiendo siempre el commit a mitad de camino entre los buenos y malos, reduciendo el rango de búsqueda de forma eficiente. Así, en lugar de probar todos los commits, solo tendremos que hacer unas pocas comprobaciones, incluso si el historial es muy largo.

Cuando finalmente git bisect encuentra el commit que introdujo el error, podemos salir de la sesión de bisect con:

git bisect reset

Esto nos devuelve al estado original antes de comenzar la búsqueda, y ya podemos investigar en detalle el commit problemático con comandos como git show.

La magia de git bisect radica en su algoritmo de búsqueda binaria, que divide el historial en mitades y descarta grandes bloques de commits en cada paso según si funcionan o no. Esto hace que encontrar el commit culpable sea mucho más rápido que revisar uno por uno.

Aunque la interfaz de git bisect puede parecer un poco compleja al principio, con sus subcomandos y la necesidad de probar manualmente cada commit que nos propone, su utilidad es enorme. Nos ahorra tiempo y esfuerzo, especialmente en proyectos con muchos commits, y nos ayuda a mantener la calidad del código al identificar rápidamente dónde se introdujo un error.

Por eso, vale la pena familiarizarse con este comando y usarlo cuando nos encontremos con bugs difíciles de rastrear. Así, podemos depurar nuestro proyecto de forma más efectiva y evitar horas de frustración buscando a ciegas.

Lista de reproducción
  1. 1
    ¿Qué es Git?
    4 minutos
  2. 2
    Cómo instalar Git
    9 minutos
  3. 3
    Creando tu primer commit
    9 minutos
  4. 4
    Qué es el staging area
    10 minutos
  5. 5
    Cómo deshacer modificaciones de archivos
    7 minutos
  6. 6
    Cómo deshacer un commit con reset
    7 minutos
  7. 7
    Cómo revertir un commit con revert
    7 minutos
  8. 8
    Introducción a las ramas
    6 minutos
  9. 9
    Cómo crear y modificar ramas
    6 minutos
  10. 10
    Commits bajo el workflow Feature Branch
    6 minutos
  11. 11
    Cómo fusionar ramas con merge
    6 minutos
  12. 12
    Fusiones conflictivas
    9 minutos
  13. 13
    Cómo construir alias
    7 minutos
  14. 14
    Más sobre conflictos
    9 minutos
  15. 15
    Etiquetas
    7 minutos
  16. 16
    Tags anotados
    9 minutos
  17. 17
    git stash: esconder cambios
    6 minutos
  18. 18
    Introducción a remotos
    5 minutos
  19. 19
    Pusheando a un remoto
    6 minutos
  20. 20
    Clonando y haciendo pull
    6 minutos
  21. 21
    Fetch y pull rebases
    8 minutos
  22. 22
    Rebase
    7 minutos
  23. 23
    Rebase interactivo
    6 minutos
  24. 24
    Master, main y otros nombres de rama
    9 minutos
  25. 25
    git switch
    9 minutos
  26. 26
    git-restore
    10 minutos
  27. 27
    git-grep
    11 minutos
  28. 28
    Gitignore
    11 minutos
  29. 29
    El flag --patch
    9 minutos
  30. 30
    git-apply y parches en bruto (advanced)
    9 minutos
  31. 31
    Merge octopus (advanced)
    9 minutos
  32. 32
    Conventional commits
    12 minutos
  33. 33
    Merge and squash (GitLab / GitHub...)
    6 minutos
  34. 34
    git merge --squash
    7 minutos
  35. 35
    git-bisect
    8 minutos
  36. 36
    git-blame
    6 minutos
  37. 37
    git-reflog
    10 minutos
  38. 38
    Git para la Bash
    11 minutos
  39. 39
    Submódulos (parte 1)
    7 minutos
  40. 40
    Submódulos (parte 2)
    10 minutos
  41. 41
    Otros clientes Git (último episodio)
    9 minutos