← Blog · 9 de abril de 2026 · Equipo de ConvertCaseHQ · 8 min de lectura

Mensajes de commit de Git: cómo escribirlos bien y con mayúsculas coherentes

Un mensaje de commit de Git limpio tiene una línea de asunto corta (apunta a 50 caracteres) escrita en modo imperativo (en inglés, «Add» y no «Added») y sin punto final. Después van una línea en blanco y un cuerpo con las líneas ajustadas a 72 caracteres que explica por qué se hizo el cambio. En cuanto a las mayúsculas, elige una convención y mantenla: con un prefijo como feat: o docs:, la palabra que viene después suele ir en minúscula; sin prefijo, el consejo clásico es poner en mayúscula la primera palabra.

Git no hace cumplir nada de esto, y por eso los historiales se van desviando. A continuación están las reglas, de dónde sale cada una y cómo hacer que tus herramientas las comprueben para que no tengas que acordarte.

Anatomía de un buen mensaje de commit

fix(editor): keep cursor position after paste

Pasting into an empty textarea moved the cursor to the start, because
the change handler replaced the value before restoring the selection.
Restore the selection after updating the value instead.

Fixes #142

Tres partes: un asunto que dice qué hace el commit, un cuerpo que dice por qué y unos pies opcionales para referencias y metadatos. La propia documentación de Git recomienda empezar con «a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description» (una sola línea corta, de no más de 50 caracteres, que resuma el cambio, seguida de una línea en blanco y luego una descripción más detallada). Todo lo que hay hasta la primera línea en blanco se trata como el título del commit, que es lo que muestran git log --oneline, git shortlog y git format-patch.

La línea de asunto: corta, en imperativo y sin punto final

Cincuenta caracteres es un límite flexible. La propia guía SubmittingPatches del proyecto Git lo llama exactamente así y pide a los colaboradores que «skip the full stop» (omitan el punto final). Si no consigues bajar de 50, suele ser señal de que el commit hace dos cosas.

La misma guía pide que «describe your changes in imperative mood» (describas tus cambios en modo imperativo), como si dieras órdenes al código: «make xyzzy do frotz», no «makes xyzzy do frotz» ni «changed xyzzy to do frotz». Una prueba útil, de las siete reglas de los mensajes de commit de Chris Beams: un buen asunto completa la frase «If applied, this commit will …» (si se aplica, este commit …).

• «If applied, this commit will add CSV export» funciona.
• «If applied, this commit will added CSV export» no funciona.
• «If applied, this commit will bug fixes» tampoco, y no le dice nada al lector.

En inglés, el imperativo también coincide con los mensajes que Git escribe por ti, como Merge branch 'main' y Revert "…", de modo que tus propios commits se leen igual en el historial.

Mayúsculas en el asunto: los dos bandos

Aquí es donde los consejos chocan de verdad, y la respuesta correcta depende de si tus asuntos empiezan con un prefijo.

La versión del proyecto Git tiene un detalle que merece la pena copiar. Solo la primera palabra después del prefijo pierde la mayúscula, y solo porque es la primera palabra: las palabras que siempre llevan mayúscula la conservan. Su propio ejemplo es refs: HEAD is also treated as a ref, porque HEAD siempre se escribe en mayúsculas. La misma lógica da fix: handle iOS paste y docs: update README badges.

Nuestra opinión: con prefijo, pon en minúscula la primera palabra, salvo que sea un nombre o una sigla. Sin prefijo, ponla en mayúscula. Mezclar los estilos es el único error de verdad, porque git log --oneline convierte tus asuntos en una lista, y una lista que cambia de mayúsculas cada pocas líneas parece descuidada. Para el mismo razonamiento aplicado a la documentación, mira nuestra guía sobre cómo escribir documentación coherente.

Qué dice de verdad la especificación Conventional Commits

La especificación Conventional Commits 1.0.0 define esta estructura:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Las reglas clave, en breve:

• feat (una función nueva) y fix (una corrección de un error) son los dos tipos que define la especificación, y se corresponden con las versiones MINOR y PATCH de Semantic Versioning; los cambios incompatibles (breaking changes) se asignan a MAJOR. Se permiten otros tipos; la especificación menciona build, chore, ci, docs, style, refactor, perf y test, tal como los recomienda la configuración conventional de commitlint, que se basa en la convención de Angular.
• Un cambio incompatible se marca con ! antes de los dos puntos (feat!: drop Node 16 support) o con un pie BREAKING CHANGE:, y ese pie debe ir en mayúsculas.
• Las herramientas que leen el formato no deben tratarlo como sensible a mayúsculas y minúsculas, salvo BREAKING CHANGE. Sobre si los tipos deben ir en minúscula o en mayúscula, las preguntas frecuentes de la especificación dicen que se puede usar cualquiera de las dos, «but it's best to be consistent» (pero lo mejor es ser coherente).

La especificación no fija una longitud para el asunto ni exige el modo imperativo. Eso viene de la convención de Git.

Dónde commitlint es más estricto que la especificación

El @commitlint/config-conventional de commitlint es la forma habitual de hacer cumplir el formato, y sus valores por defecto van más allá de la especificación. Pasamos asuntos de ejemplo por la versión 21:

La fila de README es la que hay que vigilar. Un asunto que empieza con una sigla o con el nombre de una clase, como fix: README typo o feat: URLSearchParams support, se rechaza, aunque el proyecto Git aceptaría el equivalente. Reformula el asunto para que la sigla no vaya la primera, o relaja la regla subject-case en tu configuración. El límite por defecto de la cabecera es de 100 caracteres, así que commitlint tampoco te exige los 50.

El cuerpo: ajusta a 72 y explica el porqué

Git nunca vuelve a ajustar tu mensaje. La explicación de Tim Pope de 2008 sigue vigente: git log sangra los mensajes cuatro espacios, así que en un terminal de 80 columnas, otros cuatro por simetría a la derecha dejan 72 columnas, y el texto ajustado también sigue siendo legible cuando los commits se envían por correo con git format-patch. Nuestra herramienta Ajustar texto a N caracteres ajusta un párrafo a 72 caracteres respetando los límites de las palabras, por si tu editor no lo hace.

Usa el cuerpo para lo que el diff no puede mostrar: el problema, por qué esta solución y cualquier cosa que probaste y no funcionó. Desde la línea de comandos, cada -m se convierte en su propio párrafo, así que git commit -m "fix: keep cursor after paste" -m "Pasting into…" produce un asunto, una línea en blanco y un cuerpo.

Deja que tus herramientas lo comprueben

• VS Code: activa "git.inputValidation": true. Entonces el cuadro del commit avisa cuando el asunto pasa de 50 caracteres (git.inputValidationSubjectLength) o cuando otra línea pasa de 72 (git.inputValidationLength).
• Vim: su configuración incluida para mensajes de commit ajusta el cuerpo a 72 (textwidth=72) y deja de resaltar el asunto pasados los 50 caracteres.
• Una plantilla de commit: git config commit.template ~/.gitmessage hace que cada commit empiece en el editor con tus recordatorios.
• Un hook commit-msg para hacer comprobaciones sin dependencias. Guárdalo como .git/hooks/commit-msg y hazlo ejecutable:

#!/bin/sh
# Checks the subject line of every commit message.
subject=$(head -n 1 "$1")
length=${#subject}   # counts bytes in some shells; fine for ASCII subjects

if [ "$length" -gt 72 ]; then
  echo "commit-msg: subject is $length characters (limit 72, aim for 50)" >&2
  exit 1
fi
if [ "$length" -gt 50 ]; then
  echo "commit-msg: note, subject is $length characters (aim for 50)" >&2
fi
case "$subject" in
  *.) echo "commit-msg: drop the full stop at the end of the subject" >&2
      exit 1 ;;
esac
if [ -n "$(sed -n 2p "$1")" ]; then
  echo "commit-msg: leave line 2 blank, between subject and body" >&2
  exit 1
fi

Avisa a partir de 50 caracteres y rechaza los asuntos de más de 72, un punto final sobrante o la falta de una línea en blanco; git commit --no-verify lo salta cuando de verdad lo necesitas. Para contar rápido antes de confirmar el commit, pega el asunto en nuestro Contador de caracteres.

La lista de comprobación, entonces: asunto en imperativo, de unos 50 caracteres, sin punto final, una sola regla de mayúsculas para todo el repositorio, una línea en blanco, un cuerpo ajustado a 72 que explique el porqué, y un hook o un linter para que las reglas sobrevivan a una semana de mucho trabajo.