Reglas y consejos para escribir los mensajes de los commits siguiendo una especificación.
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.
Git no obliga a ninguna regla al escribir mensajes de commit. Aplicando ciertas convenciones, preparamos el historial de commits para poder:
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 formularioBREAKING 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.