Commits Convencionales

Reglas y consejos para escribir los mensajes de los commits siguiendo una especificación.

commits-convencionales

La especificación de Commits Convencionales (Conventional Commits) es una guía sencilla para estructurar los mensajes de los commits y hacerlos más legibles. Define un conjunto básico de normas que permiten mantener un historial de commits claro y bien organizado, facilitando así el desarrollo de herramientas automatizadas basadas en dicho historial. Además, esta práctica es compatible con SemVer, ya que detalla en los mensajes de commit las nuevas funcionalidades, correcciones y cambios que introducen incompatibilidades.

Para qué usar Commits Convencionales

Git no obliga a ninguna regla al escribir mensajes de commit. Aplicando ciertas convenciones, preparamos el historial de commits para poder:

  • Generar CHANGELOGs (listados de cambios) de forma automática.
  • Determinar un salto de versión semántico (basado en los tipos de commits utilizados) de forma automática.
  • Mejorar la comunicación de la naturaleza de los cambios a las personas que lean el histórico de commits.
  • Facilitar la contribución de código al proyecto.

Elementos estructurales del mensaje de commit

El mensaje del commit debe ser estructurado de la siguiente manera:

<TipoDeCommit>[ámbito opcional]: <Descripción>
[cuerpo opcional]
[nota(s) al pie opcional(es)]

Sirve para describir y comunicar la intención de los cambios realizados en cada commit:

  • feat: cuando se desea añadir una nueva funcionalidad al código. Se correlaciona con MINOR en el Versionado Semántico (SEMVER).

  • fix: para corregir un error en el código.

  • BREAKING CHANGE. Si incluye este texto como nota al pie del texto. Ejemplo:

    feat(formulario): añadido nuevo campo en el formulario
    BREAKING CHANGE: a partir de ahora el nuevo campo será obligatorio.

    También se puede escribir con el símbolo ! (con o sin BREAKING CHANGE):

    refactor!: deja de dar soporte para Jquery 2.8

    (se correlaciona con MAJOR en el Versionado Semántico). Un BREAKING CHANGE puede ser parte de commits de cualquier tipo.

  • Se permiten distintos tipos de feat: y fix:, como build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, etre otros.

  • Se permite distintas notas al pie como Signed-off-by: Alice <[email protected]> Ver más.