7.10 Herramientas de Git - Haciendo debug con Git

Si rastreas un bug en tu código y quieres saber cuándo fue introducido y por qué, la anotación de archivo será muchas veces tu mejor herramienta. Esta te muestra qué commit fue el último en modificar cada línea de cualquier archivo. Así que, si ves que un método en tu código tiene bugs, puedes anotar el archivo con git blame para ver cuándo cada línea del método fue editada por última vez y por quién. Este ejemplo usa la opción -L para limitar la salida desde las líneas 12 a 22:

Nota que el primer campo es la parcial de SHA-1 del “commit” que modificó esa línea. Los siguientes dos campos son valores extraídos del “commit” - el nombre del autor y la fecha del commit - así podrás ver de manera sencilla quién modificó esa línea y cuándo. Tras estos viene el número de línea y el contenido del archivo. También nota las líneas del “commit” ^4832fe2, que designan que esas líneas estuvieron en el “commit” original del archivo. Ese “commit” es cuando este archivo fue introducido por primera vez al proyecto, y esas líneas no han sido modificadas desde entonces. Esto es un poco confuso, porque ahora has visto al menos tres maneras diferentes en que Git usa el ^ para modificar el SHA-1 de un “commit”, pero eso es lo que significa aquí.

Otra cosa interesante de Git, es que no rastrea los nombres de archivos de forma explícita. Registra las instantáneas y luego intenta averiguar lo que fué renombrado implícitamente, después del hecho. Una de las características interesantes de esto es que se puede preguntar todo tipo de movimiento de código también. Si pasas -C a` git blame`, Git analiza el archivo que estás anotando y trata de averiguar de dónde provienen originalmente los fragmentos de código si se copiaron desde otro lugar. Por ejemplo, digamos que estás modificando un archivo llamado GITServerHandler.m en múltiples archivos, uno de estos es GITPackUpload.m. Realizando un “blame” a GITPackUpload.m con la opción -C, se puede ver de dónde vinieron las secciones del código:

Esto es realmente útil. Normalmente, se obtiene como el “commit original” aquel de dónde se copió el código, porque esta es la primera vez en la que se tocaron estas líneas en el archivo. Git te informa el “commit original” donde se escribieron esas líneas, incluso si esto fue hecho en otro archivo.

Anotar un archivo ayuda si sabes dónde está el problema. Si no sabes lo que está mal, y ha habido decenas o cientos de “commits” desde el último estado en el que sabes que funcionó el código, probablemente recurrirás a git bisect para obtener ayuda. El comando bisect hace una búsqueda binaria a través de su historial de commits para ayudarte a identificar lo más rápidamente posible qué commit introdujo un problema.

Supongamos que acabas de emitir un release de tu código en un entorno de producción, estás recibiendo informes de errores sobre algo que no estaba ocurriendo en tu entorno de desarrollo y no puedes imaginar por qué el código lo está haciendo. Regresas a tu código, y resulta que puedes reproducir el problema, pero no puedes averiguar qué está mal. Puedes biseccionar el código para averiguarlo. Primero ejecuta git bisect start para hacer que las cosas funcionen, y luego usas git bisect bad para decirle al sistema que el “commit” actual está roto. Entonces, debes decir a bisect cuándo fue el último estado bueno conocido, usando git bisect good [good_commit]:

Git se dió cuenta de que se produjeron alrededor de 12 commits entre el commit marcado como el último commit bueno (v1.0) y la versión mala actual, y comprobó el del medio para ti. En este punto, puedes ejecutar tu prueba para ver si el problema existe a partir de este “commit”. Si lo hace, entonces se introdujo en algún momento antes de este “commit” medio; si no lo hace, entonces el problema se introdujo en algún momento después del “commit” medio. Resulta que no hay ningún problema aquí, y le dices a Git escribiendo git bisect good y continúa tu viaje:

Ahora estás en otro “commit”, a medio camino entre el que acabas de probar y tu mala comisión. Ejecutas la prueba de nuevo y descubres que este “commit” está roto, por lo que le dices a Git git bisect bad:

Este “commit” está bien, y ahora Git tiene toda la información que necesita para determinar dónde se introdujo el problema. Te dice el SHA-1 del primer “commit” erróneo y muestra algo de la información del “commit” con qué archivos se modificaron en ese “commit” para que puedas averiguar qué sucedió que pueda haber introducido este error:

Cuando hayas terminado, debes ejecutar git bisect reset para reiniciar el HEAD a donde estaba antes de comenzar, o terminará en un estado raro:

Esta es una herramienta poderosa que puede ayudarte a comprobar cientos de “commits” para un bug introducido en cuestión de minutos. De hecho, si tienes un script que retornará 0 si el proyecto está bien u otro número si el proyecto está mal, puedes automatizar completamente git bisect. En primer lugar, vuelve a decirle el alcance de la bisectriz, proporcionando los “commits” malos y buenos. Puedes hacerlo enumerándolos con el comando bisect start si lo deseas, listando primero el “commit” malo conocido y segundo el “commit” bueno conocido:

Hacerlo ejecuta automáticamente test-error.sh en cada “commit” de “check-out” hasta que Git encuentre el primer “commit” roto. También puedes ejecutar algo como make o ` make tests` o lo que sea que ejecute pruebas automatizadas para ti.