Cómo descubrir un error usando git bisect

Cómo depuro casi todos los problemas que involucran un largo historial de cambios, seguidos usando Git y descubro cuándo introdujo un error en su código

A veces trabajamos en proyectos durante mucho, mucho tiempo. Podríamos crear la versión 1.0 perfecta, luego la lanzamos al público y comenzamos a trabajar en la corrección de errores, luego recibimos solicitudes de funciones y trabajamos para mejorar la aplicación.

En algún momento durante este proceso, obtienes unerror de regresión: un problema inesperado causado por un cambio no relacionado en el código.

Algo no funciona como se esperaba, aunque realmente no cambió esa parte del código recientemente.

O tal vez tocó un archivo o función tantas veces que no puede recordar qué cambio pudo haber causado el problema que se le informó.

En cualquier caso, lo primero que hay que hacer esdeterminar dónde está el error.

Si trabaja con un sistema de control de versiones comoGit, las cosas son más fáciles. Puede retroceder en el tiempo y averiguar la confirmación exacta que introdujo el cambio. Cuando se trabaja en equipo, esto es importante porque alguna otra persona podría haber trabajado en eso, y si ellos causaron el error, es posible que no sepa qué hacer, excepto pedirles que lo corrijan, porque Git le brinda esta información.

Una forma de hacer esto es verificar manualmente alguna confirmación específica. Por ejemplo, puede comenzar verificando si la versión de ayer del código base funcionó bien.

yo sueloEscritorio de GitHub, el increíble cliente de Git deGitHub. Es genial para el uso diario, pero no me permite comprobar ni una sola confirmación. Algunos otros clientes lo hacen, pero puede utilizar ellínea de comando.

Correr

git checkout <COMMIT_SHA>

dóndees el compromiso al que desea retroceder. Se verá algo así como5a06d3ca5e7adb6e67.

Si aún tiene el problema, intente hacer lo mismo con otra confirmación del día anterior, y así sucesivamente, hasta que encuentre una confirmación en la que funcione el código.

Ahora necesitas aplicar eldivide y conquistarasprincipio, y elija una confirmación en medio de la última que probó (y no funcionó) y la que funciona.

Repita el proceso y corte a la mitad cada vez que el intervalo de confirmaciones, hasta que identifique la confirmación que introdujo el problema.

Esto es algo tan común y útil que Git introdujo elbisectcomando para automatizar este proceso.

Empiece desde su última confirmación. Usargit checkout your-branch-name, por ejemplogit checkout mastersi ya revisó una confirmación anterior.

Entonces corre:

git bisect start

No pasó nada todavía. Tienes que decirle a Git unmaloconfirmar referencia, donde el código no funciona:

git bisect bad HEAD

y unbiencommit, donde el código funcionó:

git bisect good 7f4d976e7540e28c6b0

Git inicia el proceso:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25

Mira, tienes 6 confirmaciones entre HEAD y la confirmación que mencioné como buena. Git me dice que tengo 2 pasos más hasta que encontremos el compromiso problemático.

Voy y pruebo el código, luego le digo a Git el resultado:git bisect badogit bisect gooddependiendo del éxito.

Repita hasta encontrar el compromiso incorrecto y luego ejecutegit bisect resetpara volver al compromiso HEAD.

Git te guiará en esta operación de bisección. Entras en el SHA del compromiso


Más tutoriales de git: