Una de las ventajas de usar control de versiones es poder tener a mano todo el historial de nuestro proyecto, comparar cambios, saber cuando se introdujeron, por quien y en el caso de tener que revertir poder hacerlo de una forma rapida y confiable.
Al mismo tiempo que queremos dejar un registro minucioso de como ha ido el desarrollo, tenemos que procurar que ese registro sea entendible para alguien que llegue nuevo al equipo.
Qué es conventional commits
Es una convencion a la hora de formatear los mensajes de commits de nuestro proyecto. Se definen una serie de reglas que todo el equipo va a respetar y agilizan la lectura de los commits del repositorio y nos permite automatizar ciertas acciones como por ejemplo el versionado de la aplicación.
Los conventional commits están muy ligados a Semantic Versioning. Semantic Versioning la una especificación que se sigue para versionar las aplicaciones en el desarrollo del software.
Version 3.2.1
MAJOR = 3
MINOR = 2
PATCH = 1Los incrementos de major, minor o patch indican:
- Major: un incremento que hace incompatible la API con los nuevos cambios.
- Minor: un incremento indica que se ha añadido funcionalidad pero sin romper la compatibilidad.
- Patch: un incremento que indica que se ha arreglado algún bug pero sin romper compatibilidad.
Cómo usar Conventional Commits
La forma en la que Conventional Commits define como deben ser nuestros mensajes de commit se puede resumir así:
{tipo}(scope): {descripcion}
{cuerpo}
{pie de commit}Tipo
El tipo describe el carácter del commit. Así, cualquiera que lo lea va a entender rápidamente que tipo de cambio hemos introducido, hay algunos propuestos:
- feat: cuando nuestro cambio añade una nueva funcionalidad.
- fix: en el caso que el commit arregle algún fallo existente en nuestro proyecto.
- test: es usado para introducir nuevos tests.
- docs: para añadir o corregir la documentación del proyecto.
- refactor: su propio nombre lo indica, es usado para introducir cambios de refactorización.
- revert: cuando necesitemos hacer algún revert de un cambio ya introducido en la rama.
Además, hay otros complementarios que son algo más específicos:
- chore: cambios de mantenimiento o de configuración del entorno como pueden ser meter nuevas librerías en
package.jsono cambios en el .gitignore. - build: cambios en el proceso de compilación del proyecto.
- ci: cambios que afectan a nuestro entorno de integración continua.
Scope
El scope sirve para dar contexto sobre el cambio que estamos introduciendo. Podemos usarlo para comunicar que estamos tocando la parte core del proyecto, o quizás un módulo específico del proyecto como pueden ser las traducciones o la base de datos.
Descripción
Según la especificación de Conventional Commits, la descripción debe ser:
- Concisa, siguiendo a los dos puntos después del tipo.
- Debe incluir un breve resumen sobre los cambios aplicados.
- Uso de verbos en presente como
include,addoallow.
Cuerpo
El cuerpo del commit es opcional. Suele ser incluido cuando la descripción es muy corta para dar mas contexto sobre el cambio introducido. No hay una regla específica sobre como se debe escribir, tiene un formato libre.
Pie de commit
Igual que el cuerpo es opcional. Suele ser usado para indicar que el cambio introduce cambios que rompen la retrocompatibilidad, igual que lo hacen los cambios major en Semantinc Versioning. El footer debe incluir BREAKING CHANGES en ese caso, o bien podemos poner un ! después del tipo/scope
BREAKING CHANGES: {descripcion}feat!: add new service to the user controllerEjemplos
Commit con descripción y cambios que rompen
feat: add new message suscriber
BREAKING CHANGE: this changes involve to change the messages sent to this appCommit con ! en lugar de usar BREAKING CHANGE
feat!: new user email template added to the finished book service
En conclusión, adoptar Conventional Commits en tus proyectos de Git no solo optimiza el proceso de seguimiento de cambios, sino que también mejora la colaboración dentro de los equipos de desarrollo. Al establecer un formato claro y estructurado para los mensajes de commits, facilitas la comprensión y el mantenimiento del código a largo plazo. Además, la integración con Semantic Versioning y otras herramientas de automatización puede acelerar y simplificar el lanzamiento de nuevas versiones, haciendo tu flujo de trabajo más eficiente y menos propenso a errores.
Si quieres conocer los pros y contras de usar Git, te interesa seguir leyendo este artículo.
