Un commit, una razón. Si un commit corrige un bug, renombra variables y reformatea el archivo, nadie puede revisarlo ni deshacer una sola de esas partes.
Conventional Commits. El formato es tipo(alcance): descripción, con un cuerpo y pies opcionales. La especificación solo exige feat para una funcionalidad nueva y fix para una corrección; docs, refactor, test o chore son una convención muy usada, no parte de la norma. Un cambio incompatible lleva ! antes de los dos puntos o un pie BREAKING CHANGE:.
El mensaje explica el porqué. Git recomienda un asunto corto (50 caracteres es un límite blando, no una regla), una línea en blanco y un cuerpo con el problema y por qué este cambio lo resuelve. El diff ya muestra el qué. Git pide el asunto en imperativo, como una orden al código: elegí una forma y mantenela en todo el equipo.
El tamaño importa. La guía de ingeniería de Google plantea que los cambios chicos se revisan más rápido y más a fondo, y se revierten más fácil. Como heurística, unas 100 líneas suelen ser razonables y 1000 suelen ser demasiado.
Con una IA. Un commit de 2000 líneas es muy difícil de revisar, lo haya escrito quien lo haya escrito. Dimensioná con git status y git diff HEAD --stat, agrupá por razón y commiteá de a una.
Tres ideas para llevarte:
- Un commit, una razón.
- El mensaje explica el porqué.
- Cambios chicos se revisan de verdad.