Mensajes de git commit personalizados

Qué tipo de mensaje debería escribir cada vez que almaceno cambios en mi proyecto de git?

Lo sé, hay tantas opiniones sobre este tema y mucho depende de si se trabaja solo en equipo, pero déjame decirte que la solución es simple, pero primero empecemos por definir que son los "commit messages" en git.

Qué son los Commit Messages?

Básicamente es un mensaje, y de hecho la mejor manera de comunicar el contexto sobre un cambio a otros desarrolladores que trabajan en ese proyecto y, de hecho, a su yo futuro, este mensaje es una descripción corta de los cambios realizados en una particular línea de tiempo durante la vida del proyecto (llanamente un mensaje cualquiera).

Y por qué son importantes?

Como lo mencionaba anteriormente, estos mensajes son la mejor guía para entender que cambios se hicieron en un específico momento, de hecho, los commits hablan por sí mismos porque seguramente te ha pasado que cuando ves el historial de commits y no encuentras el cambio o el archivo que crees que se modificó, inmediatamente te das cuenta del porqué debiste escribir un mejor mensaje, pues bien, ahí es cuando sabes que debes mejorar tus mensajes y mientras más corto y conciso sea el mensaje mejor (piénsalo como un mensaje siempre autoexplicativo).

Y bueno, sabemos que son y porque son importantes, pero hay alguna forma de recordar o forzarme a escribir algo que valga la pena?

La respuesta es si contundentemente, para ello existen los Commit Templates.

Commit Templates

Los Commit Templates te permiten especificar un archivo para usar como plantilla para nuevos commits, lo que básicamente significa que puedes guardar tu plantilla de mensaje dentro de un archivo en un proyecto y luego configurar Git para usarlo cada vez que hagas un git commit.

Para configurarlo simplemente debes crear el archivo .gitmessage o modificarlo en caso de que ya exista, este archivo se debe encontrar en la ruta base de tu proyecto y puedes acceder a él escribiendo el siguiente comando:

nano ~/.gitmessage

Ahora lo importante que es el contenido de este archivo, qué escribir dentro de el? 

Hay un proyecto interesante llamado conventionalcommits que busca crear un estándar para estos mensajes y la idea es crear una especificación e intentar utilizarla siempre que se hace un commit, entonces han definido el siguiente patrón:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

Y lo sé esto no dice mucho, pero traducido a algo más legible podría verse de la siguiente manera (y este sería el código a pegar dentro del arcivo .gitmessage:

# [chore/docs/feat/fix/perf/refactor/test]: [{task_id}] - [descripcion] (Max 50 caracteres)

# Por qué es necesario? (Bugfix, feature, improvements?)
- 

# Cómo este cambio arregla el problema?
-

Guarda el archivo y ahora solamente debes decirle a git que quieres utilizar este archivo como plantilla para tus mensajes de commit, y eso lo logras con el siguiente comando:

git config commit.template ~/.gitmessage
git add .
git commit

Pero espera, no hemos terminado, todavía hay algunas cosas que necesitas entender y que me imagino tienes algunas dudas y es respecto a la sintaxis, principalmente quiero enfocarme en la primera línea porque quizás pueda parecerte no muy clara.

[chore/docs/feat/fix/perf/refactor/test]:

Notarás que la plantilla tiene ciertas palabras claves y cada una de ellas significa algo diferente que se utiliza dependiendo la naturaleza del commit, por ej:

chore: Cualquier tarea de mantenimiento regular del código.

docs: Todo aquello relacionado con documentación.

feat: Determina el uso de nuevas características introducidas al proyecto.

fix: Una corrección de errores.

perf: Mejoras al rendimiento de la aplicación.

refactor: Cualquier cambio en el código que no agrega funcionalidad ni corrige errores.

test: Todo lo relacionado con pruebas.

La idea es siempre utilizar una de estas palabras claves dependiendo del tipo de cambio que se hizo en el código.

[{task_id}]

Es un identificador de seguimiento, digamos que si utilizar Jira, Redmine, Basecamp, Backlog, Asembla, etc... pues todos ellos te permiten crear tareas y asignarles un tipo, pero lo que importa es que todos general un identificador único de seguimiento, entonces la idea es relacionar ese ID con el commit. (Tip, si trabajas con Jira y Bitbucket al escribir el ID automáticamente se creará un hipervínculo).

[descripcion] (Max 50 caracteres)

50 caracteres no es un límite estricto, solo es una regla general, mantener las líneas de la descripción con esta longitud asegura que sean legibles y obliga al autor a pensar por un momento en la forma más concisa de explicar lo que está sucediendo.

Y un ejemplo claro de como quedaría estructurado el título de un mensaje, podría ser como el siguiente ejemplo:

fix: I192 - Validacion al usuario y contrasena de la pagina de login

Sé que hay otros formatos para estas plantillas, pero tengo una opinión propia acerca del contenido e incluso podría decirte que esta (en mi ejemplo) es la mejor aproximación para los mensajes porque lo que se necesita es básicamente escribir un asunto, el porqué del cambio y el cómo se arregla, otros devs dirían que se puede incluir más información y eso es a consideración de cada quien, pero yo creo que mucha de esa información la delegaría a otra plantilla que sería la de los Pull Requests (PR) que quizás en otro artículo explique que son, como se hacen y porque son importantes.

Y es todo, ahora cada vez que quieras escribir un mensaje simplemente debes de escribir en tu consola

git commit

y automáticamente te aparecerá la plantilla lista para llenarla con el contenido de tu commit, espero que te sirva y si tienes algún comentario, adelante, escríbeme, yo siempre estoy encantado de saber que mis artículos ayudan a los demás.

Happy coding!

Photo by Sydney Rae on Unsplash