Git sabe muchas cosas

Git hace un montón de cosas por nosotros; entre las más comunes/reconocidas:

• Mantiene un registro de todos los cambios/archivos en nuestros proyectos.
• Nos permite hacer desarrollo en paralelo, con múltiples personas trabajando simultáneamente.

Pero, además de eso, Git también puede responder muchas preguntas acerca de los archivos, de los autores, e incluso de cada línea de código que hemos escrito. En este post haré una pequeña demostración de las capacidades de Git en estos aspectos.

¿Quién hizo qué?

La orden
git blame responde a la siguiente pregunta: Dado un archivo, ¿quién escribió qué línea de código, cuándo, y en qué commit?

En la imagen anterior, la sección de la izquierda corresponde a la salida de git blame; los datos mostrados en cada línea son (de izquierda a derecha):

• hash del commit en el que se introdujo esa línea.
• Número de línea en el commit original.
• Autor.
• Fecha en que se introdujo la línea.

Más allá de la aplicación obvia, de ver quién es el responsable de alguna joya en el archivo, git blame es muy útil para entender por qué se hizo algo. Con frecuencia me encuentro en esta situación:

1. Leo un pedazo de código.
2. No entiendo ciertas peculiaridades.
3. Miro git blame para ubicar el commit/commits correspondientes.
4. Leo el mensaje de commit para obtener una mejor explicación sobre qué hace el código.

Para esos casos, git blame es invaluable, ya que con él puedo ubicar fácilmente los commits correspondientes, y ver la explicación del autor al respecto.

¿Qué he hecho yo?

También es posible preguntarle a git
¿qué commits he hecho yo?, usando git log --author. La siguiente es la salida de git log --author=javier en uno de los repositorios en los que trabajo:

commit a4164c6ba7f81f48a69143d4ab8d0413a84ec43e&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Tue Feb 11 17:14:39 2014 -0500&
    sentry-2619  check that the token received exists&
commit 2741e4d7403afe6c5554d449af2d8dd085b1a490&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Tue Feb 11 16:19:47 2014 -0500&
    sentry-2760  corrected validation; .clean can't assume all the required fields exist&
commit 923411825264add548a3e729ababd92882f63fee&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Tue Feb 11 15:01:51 2014 -0500&
    hotfix-dberror  readjusted token creation&
commit 391fd738d78906100e6a4ea81d14bc6454f3d196&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Tue Feb 11 14:25:15 2014 -0500&
    SENTRY-2822  ensure that token creation doesn't clash with previous tokens for the same user&
commit cee82bedd2232025c4550db6102a66950999e6f6&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Tue Feb 11 14:16:13 2014 -0500&
    hotfix-https  misc adjustments in resources included by URL&

Así es posible ver los distintos commits que he creado, y la fecha correspondiente.

Si quisiera ver el contenido de un commit, podría copiar el hash del commit que me interesa, y ver git show <HASH-DEL-COMMIT>. Pero hay una forma más sencilla: usar tig.

tig es un visor de commits para línea de órdenes, muy ligero y muy funcional.

A continuación se muestra la interfaz inicial, que uno ve al lanzar tig, mostrando un listado de commits, de manera similar a git log:

Una de las características más interesantes de tig es que, fundamentalmente, se lo puede utilizar como un visor de la salida de git log. Esto permite, entre otras tantas cosas, usarlo para ver los commits de un autor particular. En la imagen a continuación se muestra la salida de tig --author=javier

¿Cuándo se dijo algo?

La metodología de desarrollo y uso de Git en AxiaCore es sencilla:

1. Cada tarea tiene una rama con un nombre apropiado (número de tarjeta/ticket).
2. Todos los commits de dicha rama (y de dicha tarea) siempre tienen el número de la tarjeta correspondiente en el mensaje.

Con frecuencia sucede que, después de implementar algo/terminar una tarea, es necesario volver a revisarla, para hacer correcciones o cambios. Y en esos casos, es útil poder buscar los commits relacionados con esa tarea, para ver qué archivos se modificaron, y los mensajes de commit correspondientes. La orden git log --grep permite hacer precisamente eso.

git log --grep=TEXTO busca en todos los commits y ubica aquellos cuyo mensaje de commit contiene el TEXTO buscado.

A continuación se muestra la salida de
git log --grep SS-887, en uno de mis repositorios de trabajo:

commit 49c6719cdfc0acbeeb30d74828e7bbdc1846cb46&
Merge: ed73273 8c2e29a&
Author: Igor Támara <igor@axiacore.com>&
Date:   Fri Dec 20 08:15:14 2013 -0500&
    Merged in SS-887 (pull request #837)&
    filter for package list&
commit 8c2e29ac9c4617609228afa78972026fe5828403&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Fri Dec 20 07:59:34 2013 -0500&
    SS-887  tests for search&
commit 0dc86f67f940f7e9b65160aa2283968457b149cd&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Fri Dec 20 07:59:21 2013 -0500&
    SS-887  made all fields in search form optional&
commit 57ab66388319a9c91cb7d38a4df94ec03f3a9d77&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Thu Dec 19 17:26:14 2013 -0500&
    SS-887  basic test: package creation&
commit 039e1f07c8afa15cb34bb01ab1e708b143ead157&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Thu Dec 19 16:58:29 2013 -0500&
    SS-887  corrected condition to show error message&
commit dfd7e45da42d2e8fbf6f7f243d393414e7777e26&
Author: Javier Rojas <javier.rojas@axiacore.com>&
Date:   Thu Dec 19 16:58:07 2013 -0500&
    SS-887  support for search of packages by status&

No sobra decir que git log --grep funciona con cualquier texto, no sólo con los números de tarjeta.

Sin embargo, también hay que decir que git log --grep sólo es útil cuando se escriben buenos mensajes de commit; si los autores hicieron cambios, y no dieron una descripción adecuada, sencillamente no habrá información en la cual buscar. Aquí se encuentra una buena guía para escribir mensajes de commit.

También es importante tener en cuenta esto a la hora de escribir mensajes de commit ;)