Skip to content
Mis notas

Convenciones Git

Conventional Commits es una especificación empleada en numerosos proyectos conocidos que establece una serie de reglas para optimizar el historial de commits y permite a las herramientas automatizadas generar un changelog de manera más sencilla.

Trunk based development
Conventional commits
Gitflow
GitLabflow

Formato

<type>(<scope>): <subject>


<body>


<footer>

Ejemplo:

fix(middleware): ensure Range headers adhere more closely to RFC 2616


Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.


Fixes #2310
  • La primera línea no puede tener más de 70 caracteres.
  • La segunda línea siempre debe estar en blanco.
  • Las demás líneas deben ajustarse a un máximo de 80 caracteres.
  • El tipo y el alcance deben estar siempre en minúsculas.

Valores Permitidos para <type>

  • feat (nueva funcionalidad para el usuario)
  • fix (corrección de un error para el usuario)
  • docs (cambios en la documentación)
  • style (formato, puntos y comas faltantes, etc. sin cambios en el código)
  • refactor (refactorización del código, por ejemplo, renombrar una variable)
  • test (agregar pruebas faltantes, refactorización de pruebas)
  • chore (actualización de tareas de grunt, etc. sin cambios en el código)

Githook

#!/bin/sh


# Leer el mensaje de commit desde el archivo
commit_msg_file=$1
commit_msg=$(cat "$commit_msg_file")


# Expresión regular para validar el formato de Conventional Commits
conventional_regex="^(build|chore|ci|docs|feat|fix|perf|refactor|style|test)(\([a-zA-Z0-9_-]+\))?: .{1,50}"


# Validar el mensaje de commit
if ! echo "$commit_msg" | grep -Eq "$conventional_regex"; then
  echo "ERROR: El mensaje de commit no sigue el estándar de Conventional Commits."
  echo "Ejemplo válido: 'feat(login): agregar validación de usuario'"
  exit 1
fi


exit 0

Squash and merge

Para los proyectos en los que se utiliza la estrategia de “Squash and Merge” al fusionar ramas, seguir el estándar de Conventional Commits puede no ser la opción más adecuada, ya que este método combina todos los commits de una rama en uno solo al momento de la fusión, si se sigue el estándar de Conventional Commits, que requiere mensajes específicos y detallados para cada commit, muchos de estos mensajes se perderán al consolidarse en un único commit, lo cual puede ser redundante o innecesario.

En estos casos, dado que casi siempre hay una issue asociada al desarrollo, se sugiere emplear la siguiente convención para nombrar las ramas:

  • feature/... para nuevas características o funcionalidades.
  • bugfix/... para correcciones de errores.

Además, para ramas cuyo destino es la rama principal (main), se recomienda usar:

  • hotfix/... para correcciones urgentes.
  • internal/... para cambios internos o de mantenimiento.

Y para el nombre de las pull requests, se puede seguir la siguiente convención:

  • [BUGFIX-...] Nombre descriptivo o [BUGFIX-#...] Nombre descriptivo, donde BUGFIX se reemplaza por el tipo de cambio (FEATURE, HOTFIX, INTERNAL, etc.) y #... corresponde al número de la issue asociada o un identificador único. Este enfoque proporciona una referencia clara y rápida al tipo de trabajo realizado y su contexto específico, facilitando la revisión y el seguimiento de las pull requests.