Tutorial de Git Bisect

Comentar sus confirmaciones es una parte esencial para mantener un código rastreable. Te ayuda a rastrear problemas. Sin embargo, encontrar un error basándose únicamente en los comentarios es una tarea tediosa. Puede llevar mucho tiempo revisar todo el historial y averiguar cuál de las confirmaciones es la culpable.

El comando git bisect proporciona una forma de acelerar el proceso de detección de errores. Te permite identificar el problema más rápido. Con git bisect, puede definir un rango de confirmaciones que sospecha que tienen el código problemático y luego usar métodos de eliminación binaria para encontrar el inicio del problema. Encontrar errores se vuelve más rápido y fácil.

Configuremos un ejemplo y ejecutemos algunos casos de prueba para ver cómo funciona.

Configuración de ejemplo

En nuestro ejemplo, crearemos una prueba.txt y agregue una nueva línea al archivo con cada confirmación. Después de 16 confirmaciones, el estado final del archivo se verá así:

Aquí está mi buen código 1
Aquí está mi buen código 2
Aquí está mi buen código 3
Aquí está mi buen código 4
Aquí está mi buen código 5
Aquí está mi buen código 6
Aquí está mi buen código 7
Aquí está mi buen código 8
Aquí está mi código incorrecto 1 <-- BUG INTRODUCED HERE
Aquí está mi código incorrecto 2
Aquí está mi mal código 3
Aquí está mi código incorrecto 4
Aquí está mi código incorrecto 5
Aquí está mi código incorrecto 6
Aquí está mi código incorrecto 7
Aquí está mi código incorrecto 8
Aquí está mi código incorrecto 9

En el ejemplo anterior, el error entró en el código después de 8 confirmaciones. Seguimos desarrollando el código incluso después de introducir el error.

Puede crear una carpeta llamada my_bisect_test y usar los siguientes comandos desde dentro de la carpeta para crear la situación de ejemplo:

git init
echo "Aquí está mi buen código 1"> prueba.TXT
git add -A && git commit -m "Mi confirmación 1"
echo "Aquí está mi buen código 2" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 2 (v1.0.0) "
echo "Aquí está mi buen código 3" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 3"
echo "Aquí está mi buen código 4" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 4"
echo "Aquí está mi buen código 5" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 5 (v1.0.1) "
echo "Aquí está mi buen código 6" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 6"
echo "Aquí está mi buen código 7" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 7 (v1.0.2) "
echo "Aquí está mi buen código 8" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 8"
echo "Aquí está mi código incorrecto 1"> prueba.TXT
git add -A && git commit -m "Mi confirmación 9"
echo "Aquí está mi código incorrecto 2" >> prueba.TXT
git add -A && git commit -m "Mi compromiso 10"
echo "Aquí está mi código incorrecto 3" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 11"
echo "Aquí está mi código incorrecto 4" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 12 (v1.0.3) "
echo "Aquí está mi código incorrecto 5" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 13"
echo "Aquí está mi código incorrecto 6" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 14"
echo "Aquí está mi código incorrecto 7" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 15 (v1.0.4) "
echo "Aquí está mi código incorrecto 8" >> prueba.TXT
git add -A && git commit -m "Mi confirmación 16"

Comprobando el historial

Si observa el historial de las confirmaciones, verá lo siguiente:

$ git log
cometer 3023b63eb42c7fadc93c2dd18b532a44a0a6888a
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:27 2017-0800
Mi compromiso 17
cometer 10ef0286d6459cd5dea5038a54edf36fc9bfe4c3
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:25 2017-0800
Mi compromiso 16
cometer 598d4c4acaeb14cda0552b6a92aa975c436d337a
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:23 2017-0800
Mi compromiso 15 (v1.0.4)
cometer b9678b75ac93d532eed22ec2c6617e5a9d70fe7b
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:21 2017-0800
Mi compromiso 14
cometer eb3f2f7b0ebedb732ecb5f18bee786cd3cbbb521
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:19 2017-0800
Mi compromiso 13
cometer 3cb475a4693b704793946a878007b40a1ff67cd1
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:17 2017-0800
Mi compromiso 12 (v1.0.3)
cometer 0419a38d898e28c4db69064478ecab7736700310
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:15 2017-0800
Mi compromiso 11
cometer 15bc59201ac1f16aeaa233eb485e81fad48fe35f
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:13 2017-0800
Mi compromiso 10
cometer a33e366ad9f6004a61a468b48b36e0c0c802a815
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:11 2017-0800
Mi compromiso 9
cometer ead472d61f516067983d7e29d548fc856d6e6868
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:09 2017-0800
Mi compromiso 8
cometer 8995d427668768af88266f1e78213506586b0157
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:07 2017-0800
Mi compromiso 7 (v1.0.2)
cometer be3b341559752e733c6392a16d6e87b5af52e701
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:05 2017-0800
Mi compromiso 6
cometer c54b58ba8f73fb464222f30c90aa72f60b99bda9
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:03 2017-0800
Mi compromiso 5 (v1.0.1)
cometer 264267111643ef5014e92e23fd2f306a10e93a64
Autor: Zak H
Fecha: Dom 31 de diciembre 23:07:01 2017-0800
Mi compromiso 4
cometer cfd7127cd35f3c1a55eb7c6608ecab75be30b208
Autor: Zak H
Fecha: Dom 31 de diciembre 23:06:59 2017-0800
Mi compromiso 3
cometer 3f90793b631ddce7be509c36b0244606a2c0e8ad
Autor: Zak H
Fecha: Dom 31 de diciembre 23:06:57 2017-0800
Mi compromiso 2 (v1.0.0)
cometer cc163adb8a3f7b7b52411db2b3d8bab9b7fb191e
Autor: Zak H
Fecha: Dom 31 de diciembre 23:06:55 2017-0800
Mi compromiso 1

Incluso con solo un puñado de confirmaciones, puede ver que es difícil identificar la confirmación que inició el error.

Encontrar el error

Usemos git log -online para ver una versión más limpia del historial de confirmaciones.

$ git log --en línea
3023b63 Mi compromiso 17
10ef028 Mi compromiso 16
598d4c4 Mi compromiso 15 (v1.0.4)
b9678b7 Mi compromiso 14
eb3f2f7 Mi compromiso 13
3cb475a Mi compromiso 12 (v1.0.3)
0419a38 Mi compromiso 11
15bc592 Mi compromiso 10
a33e366 Mi compromiso 9
ead472d Mi compromiso 8
8995d42 Mi confirmación 7 (v1.0.2)
be3b341 Mi compromiso 6
c54b58b Mi confirmación 5 (v1.0.1)
2642671 Mi compromiso 4
cfd7127 Mi compromiso 3
3f90793 Mi compromiso 2 (v1.0.0)
cc163ad Mi compromiso 1

Queremos encontrar la situación en la que la línea "Aquí está mi código incorrecto 1 <- BUG INTRODUCED HERE” entered the picture.

Situación 1

Supongamos que recordamos que nuestro código era bueno hasta v1.0.2 y queremos comprobar desde ese momento hasta la última confirmación. Primero iniciamos el comando bisect:

$ git bisect start

Proporcionamos el límite bueno y el límite incorrecto (sin hash significa el código más reciente):

$ git bisect bueno 8995d42
$ git bisect bad

Producción:

Bisección: quedan 4 revisiones para probar después de esto (aproximadamente 2 pasos)
[3cb475a4693b704793946a878007b40a1ff67cd1] Mi confirmación 12 (v1.0.3)

El comando bisect ha encontrado el punto medio en nuestro rango definido y movió automáticamente el código para confirmar 12. Podemos probar nuestro código ahora. En nuestro caso, vamos a generar el contenido de prueba.TXT:

$ prueba de gato.TXT

Producción:

Vemos que el estado de prueba.txt está en el estado posterior al error. Entonces está en mal estado. Así que le dejamos saber al comando bisect:

$ git bisect bad

Producción:

Bisección: quedan 2 revisiones para probar después de esto (aproximadamente 1 paso)
[a33e366ad9f6004a61a468b48b36e0c0c802a815] Mi confirmación 9

Mueve nuestro código para confirmar 9. Probamos de nuevo:

$ prueba de gato.TXT

Producción:

Vemos que hemos encontrado el punto de partida del error. La confirmación "a33e366 Mi confirmación 9" es la culpable.

Finalmente, volvemos todo a la normalidad:

$ git bisect restablecer

Producción:

La posición anterior de HEAD era a33e366… Mi compromiso 9
Cambiado a la rama 'maestra'

Situación 2

En el mismo ejemplo, probemos una situación en la que otro desarrollador comienza con la premisa de que el error se introdujo entre la v1.0.0 y v1.0.3. Podemos volver a iniciar el proceso:

$ git bisect start
$ git bisect bueno 3f90793
$ git bisect bad 3cb475a

Producción:

Bisección: quedan 4 revisiones para probar después de esto (aproximadamente 2 pasos)
[8995d427668768af88266f1e78213506586b0157] Mi confirmación 7 (v1.0.2)

Bisect ha movido nuestro código para confirmar 7 o v1.0.2. Ejecutemos nuestra prueba:

$ prueba de gato.TXT

Producción:

Aquí está mi buen código 1
Aquí está mi buen código 2
Aquí está mi buen código 3
Aquí está mi buen código 4
Aquí está mi buen código 5
Aquí está mi buen código 6
Aquí está mi buen código 7

No vemos ningún código incorrecto. Entonces, déjele saber a git bisect:

$ git bisect bueno

Producción:

Bisección: quedan 2 revisiones para probar después de esto (aproximadamente 1 paso)
[a33e366ad9f6004a61a468b48b36e0c0c802a815] Mi confirmación 9

Nos ha movido a cometer 9. Probamos de nuevo:

$ prueba de gato.TXT

Producción:

Hemos vuelto a encontrar el compromiso que introdujo el error. Fue el compromiso "a33e366 Mi compromiso 9". Aunque comenzamos con un rango de sospecha diferente, encontramos el mismo error en unos pocos pasos.

Reiniciemos:

$ git bisect restablecer

Producción:

La posición anterior de HEAD era a33e366… Mi compromiso 9
Cambiado a la rama 'maestra'

Conclusión

Como puede ver en el ejemplo, git bisect nos permite identificar un problema más rápido. Es una gran herramienta para mejorar su productividad. En lugar de pasar por todo el historial de confirmaciones, puede adoptar un enfoque más sistemático para la depuración.

Estudio adicional:

https: // git-scm.com / docs / git-bisect
https: // git-scm.com / book / en / v2 / Git-Tools-Debugging-with-Git