Mensaje de commit
Pasos
- Ejecuta
git diff --staged para ver qué se va a commitear. Si no hay nada preparado, dilo y pregunta si se debe preparar todo (git add -A) o archivos específicos. Nunca hagas commit de trabajo no preparado sin preguntar.
- Ejecuta
git log --oneline -15 y empareja el estilo que veas: Conventional Commits (feat(api): …), un prefijo de ticket (ABC-123 …) o frases simples. Si no hay una convención clara, usa frases imperativas simples.
- Si los cambios preparados hacen varias cosas no relacionadas, sugiere dividirlos en commits separados antes de escribir un mensaje para todo.
Formato
<línea de resumen, modo imperativo, máximo ~72 caracteres, sin punto final>
<cuerpo: por qué se hizo el cambio y cualquier cosa que un revisor no pueda ver en el diff.
Ajustar a 72 caracteres. Omitir el cuerpo para cambios triviales.>
<trailers: Fixes #123, Co-authored-by: …, BREAKING CHANGE: …>
- Modo imperativo: "Añadir reintento en subida", no "Añadido" ni "Añade".
- El resumen dice qué cambió para el usuario o la base de código, no qué archivos se tocaron.
- El cuerpo explica por qué: el bug, la restricción, la alternativa que rechazaste. El diff ya muestra qué.
- Con Conventional Commits, elige el tipo honestamente:
feat (nuevo comportamiento), fix (bug), refactor (sin cambio de comportamiento), perf, docs, test, build, ci, chore. Marca los cambios rupturistas con ! y un trailer BREAKING CHANGE:.
Ejemplos
fix(auth): refrescar el token antes de que expire, no después
Las solicitudes realizadas en los últimos 30 segundos de vida de un token
fallaban con 401 porque el refresco solo se ejecutaba en el primer fallo.
Refrescar cuando queden menos de 60 segundos en su lugar.
Fixes #482
Eliminar endpoint de exportación CSV no utilizado