En la pasada WordCamp Europa 2019 pude disfrutar de la siguiente charla corta: Encuentra el bug que hiciste hace meses con GitBisect, de David Needham. La verdad es que me pareció interesantísima y he pensado que merece la pena resumir brevemente lo que allí aprendí, puesto que enseña cómo ahorrar un montón de tiempo a la hora de encontrar y corregir un error que hayas introducido inadvertidamente en tu código.
Cometiste un error meses atrás y ahora la web está rota. Nadie se había dado cuenta hasta hoy y tu cliente está molesto, así que tienes que arreglarlo… ¡y rápido! ¿Pero dónde y cuándo metiste la pata? Pues bien, hay una herramienta oculta en Git que te permite encontrarlo rápidamente. Git Bisect facilita navegar por todos tus commits y encontrar el culpable en segundos, incluso cuando no sabes en qué fichero o ficheros aparece el error.
Resumen de la charla en la web de la WordCamp Europa 2019.
Te dejo con la charla en cuestión, por si te apetece verla en lugar de leer esta entrada:
Cómo encontrar de forma «cutre» dónde y cuándo se introdujo un error
Pues eso, imagina que de repente algún usuario te escribe y te comenta que ha detectado un error en tu programa. Tú intuyes que este error tiene que ser reciente, porque nunca antes había aparecido… pero no tienes claro qué es lo que lo está produciendo. ¿Qué harías para encontrarlo?
La solución más cutre y sencilla que de entrada se te puede pasar por la cabeza es mirar tus últimos commits y ver a partir de cuál las cosas empiezan a fallar. Es decir, supongamos que tu proyecto tiene 100 commits y el commit número 100 es el que está usando tu cliente. Abres tu navegador, intentas reproducir el error y, efectivamente, allí está. Luego pasas al commit 99, confirmas que el error está ahí y sigues adelante. Luego haces lo propio con el commit 98, el 97… y vas repitiendo el proceso hasta que llegas a un cierto commit, el 73, por ejemplo, donde todo funciona correctamente. ¿Dónde se introdujo el problema? ¡En el 74!
Te ha costado 100-73 = 27 intentos encontrar el commit que realmente fallaba ? pero, oye, ahora ya está identificado el punto en el que apareció el error y ya puedes trabajar en la solución. ?
Nelio A/B Testing
Me sorprendió mucho la calidad del plugin, lo fácil que fue configurarlo y el increíble soporte que me dio Nelio. Recomiendo encarecidamente usar Nelio A/B Testing.
Josette Millar
Cómo encontrar el error rápidamente y de forma profesional
Ahora olvídate de la solución cutre y pasemos a usar el método que David Needham nos explicó en la WordCamp Europa 2019. Tenemos un error en el commit más reciente del proyecto y queremos encontrar dónde se introdujo dicho error… ¿qué hacemos?
Bueno, lo primero es entrar en el modo bisect de Git, que es el que nos permitirá encontrar al culpable rápidamente. Para ello, basta con introducir el siguiente comando en la carpeta de nuestro proyecto:
git bisect startEntonces, como estamos en HEAD dentro de nuestro proyecto y sabemos que este falla, le tenemos que decir a Git que el commit actual está mal:
git bisect badA continuación tenemos que indicarle algún commit pasado que sepamos (o creamos) que está bien. Por ejemplo, podemos suponer que el primerísimo commit (imagina que tiene el hash c1fd602276) del proyecto estaba bien, así que indicamos eso:
git bisect good c1fd602276Como resultado de este commando, Git saca pecho y nos dice:
Bisecting: 98 revisions left to test after this (roughly 6 steps)Vamos, que cree que encontraremos al culpable en unos 6 pasos.
Para ello, después de indicarle un punto en el que todo funciona y otro en el que todo está mal, Git nos pone automáticamente en un punto medio (es decir, nos pone en el commit número 50) y nos pregunta: «oye, ¿este está bien o mal?». Nosotros comprobamos si el commit 50 funciona o no y le decimos que sí, que funciona:
git bisect goodcon lo que Git entiende que del commit 1 al 50 todo está guay. Así que vuelve a ponernos a medio camino entre lo que sabe que está bien (el 50) y lo que está mal (HEAD), o sea, en el 75, y nos vuelve a hacer la misma pregunta: «y esto, ¿qué?». Y nosotros le decimos:
git bisect bady ahora sabe que entre el 75 y el 100 (HEAD) las cosas están mal, así que el culpable tiene que estar entre el 50 y el 75. Git Bisect va repitiendo el proceso paso a paso, descartando cada vez la mitad de los commits, hasta que vamos repitiendo el proceso y en unos 6 pasos hemos llegado a encontrar el culpable.
¡No me digas que no mola! La verdad es que las posibilidades que ofrece Git son brutales. Es increíble la de tiempo que podemos ahorrar si conocemos un poco mejor nuestras herramientas. Te recomiendo encarecidamente que no te pierdas la charla que hay enlazada de David Needham, porque en ella encontrarás más trucos que no quiero destriparte en esta entrada… pero que seguro te serán muy útiles.
Deja una respuesta