Skip to main content

Commits y convenciones (Conventional Commits)

Para mantener un historial claro, el proyecto utiliza:

  • El estándar Conventional Commits para estructurar dichos mensajes.

Tipos de commit más utilizados​

  • feat: Nueva funcionalidad
    • Ej: feat(bff-api): agregar filtro por aplicación
  • fix: Corrección de bug
    • Ej: fix(reports-api): corregir cálculo de rango de fechas
  • docs: Cambios solo de documentación
    • Ej: docs(architecture): actualizar diagrama de eventos
  • chore: Tareas internas, sin impacto directo en funcionalidad
  • Ej: chore: actualizar dependencias nx
  • refactor: Cambios internos sin modificar comportamiento observable
    • Ej: refactor(core-api): extraer servicio de auditoría
  • test: Cambios relacionados a pruebas
    • Ej: test(auth-api): agregar pruebas de reset de password
  • build / ci: Cambios en build, pipelines, scripts
    • Ej: ci: ajustar workflow de build para devs-portal

Ejemplos de buenos commits​

feat(portal-web): agregar filtros avanzados por país y sistema

fix(bff-api): normalizar payload de auditoría para evitar campos nulos

docs(development): documentar configuración de Kafka y Redpanda

Reglas básicas​

  • Usa presente en la descripción: “agregar”, “corregir”, “actualizar”.
  • No uses descripciones genéricas tipo “arreglos varios”.
  • Un commit debe ser coherente y auto-contenido:
    • Idealmente: una sola intención (feature/fix/refactor).
  • Si un cambio es muy grande, considera dividirlo en varios commits lógicos.

Hooks de Git​

El proyecto utiliza Husky + lint-staged para:

  • Verificar formato y lint en archivos modificados antes de permitir el commit.
  • Bloquear commits directos a ramas protegidas (`main).

Si un commit falla por lint o formato:

  1. Revisa el mensaje de error.
  2. Ejecuta manualmente los comandos sugeridos (por ejemplo, nx lint, nx format:write).
  3. Vuelve a correr el commit.

Esto asegura que todo el código que llega al repositorio cumple con los estándares definidos.