Cuando programamos, comunicar lo que hacemos a través de los mensajes de commit puede ser un verdadero desafío. No solo se trata de escribir código, sino también de transmitir claramente a nuestros compañeros, clientes o usuarios qué cambios hemos realizado y por qué. Aquí es donde entran en juego los convencional commits, una especificación que nos ayuda a estandarizar esos mensajes para que sean claros, uniformes y útiles.
La idea principal de los convencional commits es que cada mensaje de commit comience con una palabra clave que indique el tipo de cambio realizado. Por ejemplo, si estamos arreglando un error, el commit debe empezar con fix. Si añadimos una nueva funcionalidad, usaremos feat. Cuando simplemente reorganizamos o limpiamos el código sin añadir ni arreglar nada, el prefijo será refactor. También existen otros tipos como test para cambios relacionados con pruebas, docs para documentación, build para tareas de compilación, o chore para tareas de mantenimiento que no afectan directamente al código funcional.
Esta estructura nos permite, con solo echar un vistazo al historial de commits, entender rápidamente qué ha cambiado en el proyecto. Por ejemplo, en repositorios grandes como Angular o Nuxt.js, podemos ver cómo se repiten estos prefijos al inicio de cada mensaje, lo que facilita la navegación y revisión del código.
Además, en proyectos con múltiples módulos o directorios, podemos añadir un scope para especificar en qué parte del proyecto se ha hecho el cambio. Por ejemplo, un commit podría comenzar con feat(router): para indicar que la nueva funcionalidad está relacionada con el módulo de enrutamiento. Esto es especialmente útil en repositorios grandes donde los cambios pueden afectar áreas muy específicas.
Después del tipo y el scope, escribimos dos puntos y una breve descripción del cambio. Por ejemplo:
feat(auth): añadir soporte para autenticación con OAuth
Otra característica importante de los convencional commits es la forma de indicar cambios que rompen la compatibilidad, conocidos como breaking changes. Estos son cambios que pueden hacer que el código que dependía de versiones anteriores deje de funcionar correctamente. Para señalarlos, podemos usar un footer en mayúsculas con la etiqueta BREAKING CHANGE, explicando qué se ha modificado y cómo afecta a los usuarios. También es posible indicar un breaking change directamente en el tipo de commit añadiendo una exclamación, como en refactor!, para avisar que ese refactor rompe compatibilidad.
Por ejemplo, si cambiamos el tipo de datos que acepta una función, pasando de números a big integers, esto puede romper el código que la usaba antes. En ese caso, el commit podría verse así:
feat!: cambiar tipo de datos de la función calculadora a BigInt
BREAKING CHANGE: la función ahora acepta BigInt en lugar de Number, lo que puede romper código existente.
El footer también puede usarse para añadir metadatos, como referencias a issues o personas responsables de revisar el cambio. Esto ayuda a mantener un registro claro y organizado de por qué se hicieron ciertos commits y quién debe supervisarlos.
Una de las grandes ventajas de usar convencional commits es que podemos automatizar la generación de notas de versión o changelogs. Herramientas como Standard Version leen el historial de commits, identifican los tipos de cambios según sus prefijos y generan automáticamente un archivo que resume qué se ha añadido, arreglado o modificado en cada versión. Esto facilita mucho la tarea de mantener a los usuarios informados sobre las novedades y correcciones en cada actualización.
En definitiva, adoptar convencional commits nos ayuda a mantener un lenguaje común en nuestros proyectos, mejora la comunicación entre todos los involucrados y permite aprovechar herramientas que automatizan procesos importantes como la creación de changelogs. Aunque pueda parecer una moda más, es una moda con un propósito claro y beneficioso para cualquier equipo de desarrollo.