Mensajes de commit en Git

Si bien a lo largo del tiempo se han identificado una serie de indicaciones relacionadas con el uso de ramas y estrategias de fusión con "git workflow", no debemos olvidar que las estrategias y convenciones vinculadas al uso de mensajes de commit también contribuyen a un uso productivo de Git y el uso de etiquetas para el control de versiones. Incluso en este aspecto, Git no es prescriptivo, dejando que cada uno elija la forma más adecuada.

Mensajes de commit en Git

En lo que respecta a los mensajes de commit, es importante recordar que Git permite insertar un mensaje de commit de varias líneas y luego usar la primera línea del mensaje como "asunto" (a partir de este punto, la diferencia entre git log y git log --oneline).

Un mensaje de commit para agregar esta sección podría verse así:

Add commit message section in workflow chapter

More specific info about how to write a commit message and some
guidelines about why it is important to keep them consistent.

We opted to suggest the following:

- use short first line as summary (less than 72 chars, 50 is best)
- wrap body lines to 72 chars (useful to read log on terminal)
- use imperative form for first summary line: "Fix bug", not "Fixed
  bug" or "Fixes bug"
- do the best to format body part to make it readable
- use body part to describe how and why for the commit, as well as
  references to other commits, issues, ...
- think if, in 6 months, you'll be able to understand the change just
  reading the commit message ;-)

Complete and close issue #12 

En resumen:

• la primera línea del mensaje es la más importante
• las otras líneas se pueden usar para aclarar referencias, razones y limitaciones relacionadas con los cambios guardados en el commit, que tal vez no fue necesario o posible agregar directamente en los archivos de proyecto modificados
• es útil ajustarse a un estilo común y consistente de saber qué y cómo encontrar información en los mensajes de commit

Una convención sobre los mensajes de commit que se comparte bastante en el mundo del desarrollo es la que toma el nombre de Conventional Commit (o Semantic Commit). Esta convención indica algunas reglas simples para crear un historial de commit explícito (¿qué tipo de modificación hice con ese commit?) e interpretable por scripts/automatizaciones.

Un mensaje de commit en línea con la especificación de Conventional Commit se estructura de la siguiente forma:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

y las siguientes reglas:

• el <type> tiene que ser fix para aquellos commit que corrigen un bug
• el <type> tiene que ser feat si elcommit introduce una nueva función
• <type> diferentes fix y feat están permitidos, sugiriendo algunos (build, chore, ci, docs, style, refactor, perf, test), pero dejando también al team definir eventualmente lo suyos
• si el commit introduce breaking change, estos deben señalarse comenzando el footer con BREAKING CHANGE: o añadiendo ! después del type/scope en la primera línea.

Si quisiéramos reescribir el mensaje de commit del ejemplo anterior con estas pautas, podremos, por ejemplo, tener algo como lo siguiente:

feat(workflows): add commit messages section

More specific info about how to write a commit message and some
guidelines about why it is important to keep them consistent.

- basic sane guidelines for commit messages
- reference to conventional commit guidelines

Refs: #2472
Reviewed-by: myself

La elección de los alcances y otras partes opcionales de las convenciones obviamente se deja al equipo, que puede ajustarse según sus necesidades.

Para obtener más información, consulte el sitio web de ConventionalCommits.