¿Cómo sueles hacer commits de código?

Utilizo un formato de commits estandarizado, a menudo basado en Conventional Commits. Esto garantiza coherencia y automatiza algunos procesos, como la generación del registro de cambios.

Formato típico de commit:

<tipo>[(área)]: <descripción>

[<cuerpo>]

[<nota>]

• <tipo>: Obligatorio. Define el tipo de cambios (por ejemplo, feat para nuevas funcionalidades, fix para correcciones, docs para cambios en la documentación, style para formateo, refactor para refactorización, test para añadir pruebas, ci para cambios en CI/CD).
• (área): Opcional. Indica la área de la aplicación afectada por los cambios (por ejemplo, (componente: botón), (servicio: autenticación)).
• <descripción>: Obligatorio. Breve y precisa descripción de los cambios en modo imperativo (por ejemplo, "añadir botón", "corregir error de validación").
• <cuerpo>: Opcional. Explicación más detallada de los cambios, motivos y contexto. Separado por una línea vacía de la descripción.
• <nota>: Opcional. Usualmente para indicar BREAKING CHANGE con descripción de por qué rompe la compatibilidad hacia atrás, o enlaces a tareas (por ejemplo, Closes #123).

Ejemplos:

feat: añadir componente de ventana modal

fix(validación): corregir error de validación de email en formulario de registro

Ahora el email se valida correctamente según la norma RFC 5322.

Closes #45

refactor(componente: botón): actualizar estilos y mejorar accesibilidad

Refactorización de estilos del botón para cumplir con el sistema de diseño.
Mejorada la accesibilidad añadiendo atributos ARIA.

Esto ayuda al equipo a entender mejor la historia de cambios, acelera la revisión del código y simplifica los procesos automatizados.