Tutorial de bisectas de git
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 una variedad de confirmaciones que sospecha que tiene el código problemático y luego utilizar métodos de eliminación binaria para encontrar el inicio del problema. Encontrar errores se vuelve más rápido y más fácil.
Configurar un ejemplo y ejecutar algunos casos de prueba para ver cómo funciona.
Configuración de ejemplo
En nuestro ejemplo, crearemos una prueba.archivo txt y agregar una nueva línea al archivo con cada confirmación. Después de 16 compromisos, 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 malo 1 <-- BUG INTRODUCED HERE
Aquí está mi código malo 2
Aquí está mi código malo 3
Aquí está mi código malo 4
Aquí está mi código malo 5
Aquí está mi código malo 6
Aquí está mi código malo 7
Aquí está mi código malo 8
Aquí está mi código malo 9
En el ejemplo anterior, el error entró en el código después de 8 comodidades. 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 el interior de la carpeta para crear la situación de ejemplo:
git init
echo "Aquí está mi buen código 1"> prueba.TXT
Git Agregar -a && git commit -m "mi commit 1"
echo "Aquí está mi buen código 2" >> prueba.TXT
git add -a && git commit -m "mi commit 2 (v1.0.0) "
echo "Aquí está mi buen código 3" >> prueba.TXT
git Agregar -a && git commit -m "mi commit 3"
echo "Aquí está mi buen código 4" >> prueba.TXT
Git Agregar -a && git commit -m "mi commit 4"
echo "Aquí está mi buen código 5" >> prueba.TXT
git add -a && git commit -m "mi commit 5 (v1.0.1) "
echo "Aquí está mi buen código 6" >> prueba.TXT
Git Agregar -a && git commit -m "mi commit 6"
echo "Aquí está mi buen código 7" >> prueba.TXT
git add -a && git commit -m "mi compromiso 7 (v1.0.2) "
echo "Aquí está mi buen código 8" >> prueba.TXT
Git Agregar -a && git commit -m "mi commit 8"
echo "Aquí está mi código malo 1"> prueba.TXT
Git Agregar -a && git commit -m "mi commit 9"
echo "Aquí está mi código malo 2" >> prueba.TXT
git Agregar -a && git commit -m "mi commit 10"
echo "Aquí está mi código malo 3" >> prueba.TXT
Git Agregar -a && git commit -m "mi commit 11"
echo "Aquí está mi código malo 4" >> prueba.TXT
git add -a && git commit -m "mi compromiso 12 (v1.0.3) "
echo "Aquí está mi código malo 5" >> prueba.TXT
Git Agregar -a && git commit -m "mi commit 13"
echo "Aquí está mi código malo 6" >> prueba.TXT
Git Agregar -a && git commit -m "mi commit 14"
echo "Aquí está mi código malo 7" >> prueba.TXT
git add -a && git commit -m "mi commit 15 (v1.0.4) "
echo "Aquí está mi código malo 8" >> prueba.TXT
git Agregar -a && git commit -m "mi commit 16"
Historia de corrección
Si miras la historia de los compromisos, ve lo siguiente:
Log de $ git
Commit 3023B63EB42C7FADC93C2DD18B532A44A0A6888A
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:27 2017 -0800
Mi commit 17
Commit 10EF0286D6459CD5DEA5038A54EDF36FC9BFE4C3
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:25 2017 -0800
Mi commit 16
Commit 598D4C4ACAEB14CDA0552B6A92AA975C436D337A
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:23 2017 -0800
Mi commit 15 (v1.0.4)
Commit B9678B75AC93D532EED22EC2C6617E5A9D70FE7B
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:21 2017 -0800
Mi commit 14
Commit EB3F2F7B0EBEDB732ECB5F18BEE786CD3CBBB521
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:19 2017 -0800
Mi commit 13
Commit 3CB475A4693B704793946A878007B40A1FF67CD1
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:17 2017 -0800
Mi commit 12 (v1.0.3)
Commit 0419A38D898E28C4DB69064478ECAB7736700310
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:15 2017 -0800
Mi commit 11
Commit 15BC59201AC1F16AEAA233EB485E81FAD48FE35F
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:13 2017 -0800
Mi commit 10
Commit A33E366AD9F6004A61A468B48B36E0C0C802A815
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:11 2017 -0800
Mi comisión 9
Commit EAD472D61F516067983D7E29D548FC856D6E6868
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:09 2017 -0800
Mi commit 8
Commit 8995D427668768AF88266F1E78213506586B0157
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:07 2017 -0800
Mi commit 7 (v1.0.2)
Commit BE3B341559752E733C6392A16D6E87B5AF52E701
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:05 2017 -0800
Mi commit 6
Commit C54B58BA8F73FB464222F30C90AA72F60B99BDA9
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:03 2017 -0800
Mi commit 5 (v1.0.1)
Commit 264267111643ef5014e92e23fd2f306a10e93a64
Autor: Zak H
Fecha: Sol 31 de diciembre 23:07:01 2017 -0800
Mi commit 4
Commit CFD7127CD35F3C1A55EB7C6608ECAB75BE30B208
Autor: Zak H
Fecha: Sol 31 de diciembre 23:06:59 2017 -0800
Mi commit 3
Commit 3F90793B631DDCE7BE509C36B0244606A2C0E8AD
Autor: Zak H
Fecha: Sol 31 de diciembre 23:06:57 2017 -0800
Mi commit 2 (v1.0.0)
Commit CC163ADB8A3F7B7B52411DB2B3D8BAB9B7FB191E
Autor: Zak H
Fecha: Sol 31 de diciembre 23:06:55 2017 -0800
Mi commit 1
Incluso con solo un puñado de compromisos, 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 de la historia de confirmación.
$ git log -enneline
3023b63 mi commit 17
10EF028 mi commit 16
598D4C4 My Commit 15 (V1.0.4)
b9678b7 mi commit 14
eb3f2f7 mi commit 13
3CB475A My Commit 12 (V1.0.3)
0419a38 mi commit 11
15BC592 mi commit 10
a33e366 mi commit 9
ead472d mi commit 8
8995D42 My Commit 7 (V1.0.2)
be3b341 mi commit 6
C54B58B My Commit 5 (V1.0.1)
2642671 mi commit 4
cfd7127 mi commit 3
3F90793 My Commit 2 (V1.0.0)
cc163ad my commit 1
Queremos encontrar la situación en la que la línea "Aquí está mi código malo 1 <- BUG INTRODUCED HERE” entered the picture.
Situación 1
Supongamos que recordamos que nuestro código fue bueno hasta V1.0.2 y queremos verificar desde ese momento hasta la última confirmación. Primero iniciamos el comando bisection:
$ git bisect Start
Proporcionamos el buen límite y el límite malo (sin hash significa el último código):
$ git bisect Good 8995d42
$ git bisect bad
Producción:
Bisectante: 4 revisiones que quedan para probar después de esto (aproximadamente 2 pasos)
[3CB475A4693B704793946A878007B40A1FF67CD1] My Commit 12 (V1.0.3)
El comando bisecto ha encontrado el punto medio en nuestro rango definido y ha movido automáticamente el código para confirmar 12. Podemos probar nuestro código ahora. En nuestro caso, vamos a generar el contenido de la prueba.TXT:
Prueba de $ Cat.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
Aquí está mi buen código 8
Aquí está mi código malo 1 <-- BUG INTRODUCED HERE
Aquí está mi código malo 2
Aquí está mi código malo 3
Aquí está mi código malo 4
Vemos que el estado de la prueba.TXT está en el estado posterior a la bug. Entonces está en el mal estado. Entonces nos hemos hecho saber Bisection Command:
$ git bisect bad
Producción:
Bisectación: 2 revisiones que quedan para probar después de esto (aproximadamente 1 paso)
[A33E366AD9F6004A61A468B48B36E0C0C802A815] MI COMIMENCIO 9
Mueve nuestro código para cometer 9. Probamos de nuevo:
Prueba de $ Cat.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
Aquí está mi buen código 8
Aquí está mi código malo 1 <-- BUG INTRODUCED HERE
Vemos que hemos encontrado el punto de partida del error. El compromiso "A33E366 My Commit 9" es el culpable.
Finalmente, volvemos a poner todo a la normalidad:
$ git bisect rein
Producción:
La posición anterior de la cabeza fue A33E366 ... mi commit 9
Cambio a la rama 'maestro'
Situación 2
En el mismo ejemplo, intentemos una situación en la que otro desarrollador comience con la premisa de que el error se introdujo entre V1.0.0 y V1.0.3. Podemos comenzar el proceso nuevamente:
$ git bisect Start
$ git bisect Good 3F90793
$ git bisect bad 3cb475a
Producción:
Bisectante: 4 revisiones que quedan para probar después de esto (aproximadamente 2 pasos)
[8995D427668768AF88266F1E78213506586B0157] My Commit 7 (V1.0.2)
Bisect ha movido nuestro código para cometer 7 o V1.0.2. Ejecutemos nuestra prueba:
Prueba de $ Cat.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 malo. Entonces, haz que Git bisect sepa:
$ git bisect bien
Producción:
Bisectación: 2 revisiones que quedan para probar después de esto (aproximadamente 1 paso)
[A33E366AD9F6004A61A468B48B36E0C0C802A815] MI COMIMENCIO 9
Nos ha trasladado a cometer 9. Probamos de nuevo:
Prueba de $ Cat.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
Aquí está mi buen código 8
Aquí está mi código malo 1 <-- BUG INTRODUCED HERE
Hemos encontrado nuevamente el compromiso que introdujo el error. Era el compromiso "A33E366 My Commit 9". Aunque comenzamos con el rango de sospecha diferentes, encontramos el mismo error en unos pocos pasos.
Reiniciemos:
$ git bisect rein
Producción:
La posición anterior de la cabeza fue A33E366 ... mi commit 9
Cambio a la rama 'maestro'
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 toda la historia de los compromisos, 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