En el desarrollo de software, es obligatorio contar con herramientas y prácticas que promuevan una comunicación clara y efectiva en la gestión de versiones. Por lo tanto es necesario conocer Conventional Commit y Semantic Versioning, dos conceptos que se complementan perfectamente para lograr un desarrollo de software más estructurado, trazable y compatible.
Primero, Conventional Commit es una convención de nomenclatura para los mensajes de confirmación de código, que establece un formato estándar para su redacción. Proporciona una estructura clara y descriptiva para los mensajes de confirmación, lo que facilita la interpretación y el seguimiento de los cambios realizados en un proyecto.
Asi mismo, Semantic Versioning es un enfoque de numeración de versiones que se basa en reglas claras y consistentes para asignar versiones a un proyecto de software. Consiste en tres componentes principales: Cambio Major (Mayor), Cambio Minor (Menor) y Cambio Patch (Parche). Cada uno de estos componentes tiene un significado específico y se actualiza según el tipo de cambio realizado en el proyecto.
Al combinar Conventional Commit con Semantic Versioning, podemos lograr una gestión de versiones más coherente y comprensible en el desarrollo de software. Les comparto algunos ejemplos (los mas comunes que usamos en nuestro equipo), para utilizar Conventional Commit teniendo en cuenta Semantic Versioning:
Ejemplo con feat (Característica)
Supongamos que estamos construyendo una aplicación de gestión de tareas y hemos implementado una nueva característica o funcionalidad que permite a los usuarios asignar tareas a otros miembros del equipo.
git commit -m "feat(Módulo de proyectos): agregar asignación de tareas a miembros del equipo
Hemos añadido la funcionalidad que permite a los usuarios asignar tareas a otros miembros del equipo. Esto mejora la colaboración y la distribución eficiente de responsabilidades. Aborda la Issue #567."En este ejemplo, la palabra clave feat se usa para denotar la implementación exitosa de una nueva característica en la aplicación. El mensaje de confirmación proporciona una descripción clara de lo que se ha hecho y cómo beneficia a los usuarios.
Por lo tanto pasamos de una versión 1.1.0 a 1.2.0.
Ejemplo con fix (Corrección)
En este caso, la palabra clave fix se utiliza para describir una corrección de error. Por lo tanto pasamos de una versión 1.2.0 a 1.2.1:
git commit -m "fix(Módulo de usuarios): solucionar problema con la carga de imágenes de perfil
Se ha corregido un error en la carga de imágenes de perfil de usuario que no funcionaba correctamente. Se ha actualizado el punto final de carga de archivos para manejar imágenes de manera adecuada. Cierra la Issue #456."Ejemplo con Breaking Change (Cambio disruptivo)
La introducción de un nuevo método de pago y los cambios asociados en la base de datos y la lógica de procesamiento son cambios significativos que afectarán la funcionalidad existente. En este caso requiere un incremento MAJOR debido a un cambio disruptivo (break):
feat(Módulo de pagos): agregar nuevo método de pago
Hemos agregado un nuevo método de pago mediante transferencia bancaria. Los usuarios ahora pueden seleccionar esta opción durante el proceso de pago. Sin embargo, esta adición afecta la estructura de la base de datos de pagos y requiere cambios en la lógica de procesamiento de pagos existente.
BREAKING CHANGE: Se ha modificado la estructura de la tabla de pagos para incorporar el nuevo método. Los scripts de migración deben actualizarse para reflejar esta modificación. Además, la lógica de procesamiento de pagos se ha actualizado para manejar el nuevo método de transferencia bancaria.La sección «BREAKING CHANGE» resalta que este cambio rompe la compatibilidad con versiones anteriores y requiere un incremento MAJOR en Semantic Versioning. El aumento del número de versión resultante MAJOR de 1.2.1 a 2.0.0 indica claramente que se ha producido un cambio disruptivo que requiere atención por parte de los usuarios y desarrolladores para mantener la funcionalidad y la integridad del sistema.
Como podemos apreciar los tipos de commits «feat», «fix» y «break» están directamente relacionados con Semantic Versioning y desempeñan un papel importante en la determinación de las versiones semánticas.
Otros tipos de commits mas usados y que no afectan el versionamiento, tenemos:
Ejemplo con chore (Tarea de mantenimiento)
Imaginemos que estamos trabajando en un proyecto web y necesitamos actualizar una librería de terceros para corregir problemas de seguridad.
git commit -m "chore(dependencies): actualizar librería 'bcrypt' a la última versión
Hemos actualizado la librería 'bcrypt' a su versión más reciente para abordar problemas de seguridad reportados en versiones anteriores. Esto es una tarea de mantenimiento esencial para mantener el proyecto seguro y actualizado."Ejemplo con docs (Documentación)
Para cambios en la documentación, se usa la palabra clave docs:
git commit -m "docs(readme): actualizar instrucciones de instalación
Se han actualizado las instrucciones de instalación en el archivo README para incluir pasos más detallados para configurar el proyecto. Esto ayudará a nuevos colaboradores a ponerse en marcha más fácilmente."Ejemplo con style (Estilo)
Imaginemos que estamos trabajando en un proyecto web y queremos mejorar la coherencia en el formato y estilo del código.
git commit -m "style(navbar): corregir formato inconsistente en la barra de navegación
Hemos corregido la sangría inconsistente en el código de la barra de navegación para mantener un formato limpio y coherente. Esto mejora la legibilidad del código y facilita futuras revisiones y colaboraciones."En todos los ejemplos vale destacar que el cuerpo y el pie son opcionales.
En conclusión, la combinación de Conventional Commit y Semantic Versioning es un activo invaluable en el arsenal de cualquier equipo de desarrollo. Estas prácticas brindan orden, coherencia y claridad a través del ciclo de desarrollo, mejorando la comunicación, el mantenimiento y la eficiencia en la colaboración. En última instancia, son esenciales para entregar software de calidad en un entorno colaborativo y en constante evolución.
Fuentes:
Conventional Commit: https://www.conventionalcommits.org
Semantic Versioning: https://semver.org/
Enamorado del blues, la trova y el rock. Un apasionado a tiempo completo de la tecnología, pivoteo y me adapto a cada nuevo paso que se da. Busco continuamente las mejores prácticas y metodologías para asegurar la calidad en el software y los procesos de negocio. Algunas horas las dedico a buscar conocimiento en filosofía y teología.