Convención de Commits de Git

​

Formato Obligatorio

<type>(<scope>): <subject>
<LÍNEA EN BLANCO>
[optional body]
<LÍNEA EN BLANCO>
[optional footer(s)]

​

Reglas y Componentes

1. Type: Define el tipo de cambio. Debe ser uno de los tipos permitidos listados abajo.
2. Scope: Debe proporcionarse y estar encerrado entre paréntesis. Indica la parte lógica del código base afectada (ej., core, services, radicacion, asignacion, auth, ds-tw). Elige el scope más relevante.
3. Subject: Descripción concisa (< 50 caracteres recomendado) del cambio en modo imperativo y minúsculas (ej., “add,” “fix,” “update”). No debe terminar con un punto.
4. Body (Opcional): Úsalo para proporcionar contexto, motivación o detalles. Sepáralo del subject con una línea en blanco. Ajusta las líneas a 72 caracteres.
5. Footer (Opcional): Úsalo para referenciar IDs de issues (ej., Refs ADO-123, Fixes #456) y es obligatorio para notificaciones de BREAKING CHANGE:. Sepáralo del body con una línea en blanco.

​

Tipos de Commit Estándar (con Ejemplos)

• ✨ feat(<scope>): <description>
  • Propósito: Introduce una nueva característica o funcionalidad visible para el usuario final.
  • Ejemplo: feat(radicacion): add drag-and-drop file upload for expedientes
• 🐛 fix(<scope>): <description>
  • Propósito: Corrige un error (bug) en el código base.
  • Ejemplo: fix(services): handle null priority in DefaultAsignacionService
• 📚 docs(<scope>): <description>
  • Propósito: Cambios relacionados únicamente con la documentación (READMEs, guías, comentarios en el código).
  • Ejemplo: docs(core): update UserService interface method descriptions
• 🎨 style(<scope>): <description>
  • Propósito: Ajustes de estilo de código (formato, espacios en blanco, punto y coma) sin cambiar la lógica. Aplicable también al uso o configuración del Design System (ds-tw scope si se modifica el DS mismo).
  • Ejemplo: style(radicacion): apply consistent padding using ds-tw vars
• ♻️ refactor(<scope>): <description>
  • Propósito: Reestructuración de código existente sin cambiar su comportamiento externo (mejorar legibilidad, extraer métodos, etc.).
  • Ejemplo: refactor(services): extract common validation logic in UserService implementations
• ⚡️ perf(<scope>): <description>
  • Propósito: Cambios en el código destinados específicamente a mejorar el rendimiento.
  • Ejemplo: perf(web): optimize image loading on dashboard page using next/image
• 🧪 test(<scope>): <description>
  • Propósito: Añadir nuevas pruebas o modificar las existentes. Sin cambios en el código de producción.
  • Ejemplo: test(services): add unit tests for DefaultUserService
• 🏗️ build(<scope>): <description>
  • Propósito: Cambios que impactan el proceso de build, dependencias o configuración del proyecto (ej., pnpm, config de Next.js, Docker, config de Turborepo).
  • Ejemplo: build(deps): upgrade xstate to v5
• ⚙️ ci(<scope>): <description>
  • Propósito: Modificaciones a la configuración o scripts de Integración Continua/Despliegue Continuo (ej., GitHub Actions, Azure Pipelines).
  • Ejemplo: ci: add type checking stage to github actions workflow
• 🧹 chore(<scope>): <description>
  • Propósito: Tareas rutinarias o mantenimiento que no encajan en otros tipos (ej., actualizar .gitignore, configuración de herramientas, tareas de release).
  • Ejemplo: chore: update eslint configuration rules for new plugin
• ⏪️ revert(<scope>): <description>
  • Propósito: Revierte un commit anterior. El subject debe indicar claramente qué se está revirtiendo.
  • Ejemplo: revert: feat(radicacion): remove experimental search feature
  • El body DEBE explicar la razón de la reversión y referenciar el hash del commit original.

​

BREAKING CHANGES

• Cualquier commit que introduzca un cambio incompatible hacia atrás (backward-incompatible) debe incluir una sección de footer BREAKING CHANGE:.
• Esta sección debe comenzar con las palabras exactas BREAKING CHANGE:, seguidas de una descripción detallada del cambio, la justificación y cualquier instrucción de migración necesaria.

refactor(core): change user ID from number to UUID

BREAKING CHANGE: El tipo del campo User.id cambió de number a string (UUID).
Razón: Necesidad de identificadores únicos globales en sistemas federados.
Migración: Se requiere actualización del esquema de base de datos (ejecutar script de migración V3). Los consumidores de la API deben adaptarse para esperar IDs de tipo string en lugar de numbers para todos los endpoints de usuario. Consultar la guía de migración enlazada en ADO-789 para detalles.