Búsqueda binaria por la historia

git bisect realiza una búsqueda binaria entre commits para encontrar el que introdujo un bug. Dado un commit conocido como bueno y otro conocido como malo, Git revisa commits intermedios y te pide que pruebes. Cada respuesta divide el espacio de búsqueda a la mitad, así que 1024 commits se resuelven en unos 10 pasos.

Sesión manual de bisect

git bisect start
git bisect bad                    # commit actual es malo
git bisect good v2.4.0            # este tag antiguo era bueno
# Git revisa el punto medio
# Prueba el build, luego:
git bisect bad                    # o: git bisect good
# Continúa hasta que Git nombre el primer commit malo
git bisect reset                  # vuelve a la rama original

Términos personalizados

A veces "good/bad" no es el vocabulario correcto — por ejemplo, al bisectar una regresión de rendimiento podrías preferir "fast/slow":

git bisect start --term-old fast --term-new slow
git bisect slow
git bisect fast v2.4.0

Saltarse commits no probables

Si el commit revisado no se puede probar, usa git bisect skip. Git escogerá un commit cercano y se ajustará.

git bisect skip
git bisect skip <sha1> <sha2>

Visualizar

git bisect visualize
git bisect log > bisect.log
git bisect replay bisect.log

Restringir la búsqueda

Si sospechas que la regresión está en un subdirectorio:

git bisect start -- src/parser/

Errores comunes

Olvidar marcar los puntos extremos iniciales — Git no puede bisectar sin uno bueno y uno malo. Marcar incorrectamente un commit envenena la búsqueda.

Bisecting por primer padre

Desde Git 2.29, --first-parent indica seguir solo el primer padre de cada merge:

git bisect start --first-parent