Plantillas de mensaje de commit de Git

Descripción general de la categoría de plantilla

Los mensajes de commit consistentes hacen legible la historia de un repositorio, permiten changelogs automáticos y agilizan la revisión de código — pero escribir a mano un Conventional Commit bien estructurado cada vez es lo bastante tedioso como para que la mayoría de desarrolladores recurra a resúmenes de una línea. Un expansor de texto lo resuelve convirtiendo un disparador corto en un andamiaje de commit completo con el tipo, scope, resumen, body y footer ya dispuestos, de modo que rellenas los detalles en lugar de recordar el formato. Como Lightning Assist funciona en todo el sistema — incluido el terminal, donde de hecho ocurren la mayoría de los commits, y la caja de commit de VS Code — las mismas plantillas funcionan tanto si haces commit desde la línea de comandos, tu IDE o una GUI de Git. La voz Push-to-Talk puede incluso dictar el párrafo más largo del body cuando tienes las manos fuera del teclado a mitad de un debug.

Cuándo utilizar estas plantillas

Usa plantillas de mensaje de commit en cada commit, pero rinden más en los commits que importan después: las correcciones de errores que revisitarás, los breaking changes que afectan a otros equipos y cualquier commit en un repo que genere releases o changelogs automáticamente a partir del historial. Si tu proyecto usa Conventional Commits, semantic-release o cualquier automatización de changelog, un andamiaje consistente no es solo orden — es lo que hace que la tooling funcione. Incluso en proyectos en solitario, un git log legible escrito en un formato consistente ahorra tiempo real cuando haces bisect de una regresión o intentas recordar por qué se hizo un cambio hace seis meses.

Plantillas de ejemplo en esta categoría

• Andamiaje de Conventional Commit: tipo, scope opcional, resumen, body y footer con referencia de ticket.
• Commit de fix con contexto del bug: qué se rompió, el arreglo y el issue que cierra.
• Commit de breaking change: el cambio más un footer BREAKING CHANGE claramente marcado para la tooling de release.

Plantillas de ejemplo en la práctica

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

Cómo empezar

Empieza con el andamiaje general de Conventional Commit en un disparador corto como ;cc, con marcadores para tipo, scope, resumen, body y ticket. Añade una variante ;fix prerellenada con el tipo fix y un footer «Closes #», y una variante ;ccbreak con el footer BREAKING CHANGE para los raros pero importantes commits que rompen compatibilidad. Escribe el disparador en tu terminal o la caja de commit de tu editor y se expande en línea mientras escribes — sin tecla rápida, y funciona igual en ambos porque la expansión es de todo el sistema. Cuando los andamiajes te resulten naturales, añade plantillas de descripción de PR y de respuesta de revisión de código para que todo el flujo de envío de cambios sea consistente.

Consejos profesionales

• Mantén la línea de resumen por debajo de ~50 caracteres y en imperativo («add», no «added») — la mayoría de la tooling de git y los revisores esperan esta convención.
• Usa un footer «Closes #[issue]» en los commits de fix para que hacer merge del cambio cierre automáticamente el ticket enlazado en tu tracker.
• Reserva la plantilla de breaking change para cambios de contrato reales e incluye siempre el paso de migración — una nota de ruptura sin él solo genera carga de soporte.
• Dicta el body del commit con Push-to-Talk cuando tengas las manos fuera del teclado a mitad de un debug, y luego compacta la redacción con AI Enhance.