Mensajes de commit con el sujeto primero
El debate entre los mensajes de commit con “sujeto primero” y los tradicionales con verbo primero pone de relieve lo distinto que usan los equipos el historial del control de versiones. Algunos ingenieros recorren los logs y quieren asuntos concisos que destaquen el componente o comportamiento afectado, mientras que otros rara vez vuelven a mirar los commits y ven los formatos estrictos como discusiones triviales de bajo retorno frente a los diffs, las PR y los rastreadores de incidencias. El intercambio plantea preguntas más profundas sobre si los mensajes de commit deben servir principalmente a las personas o a las herramientas, cuánto “por qué” debe vivir en Git frente a los sistemas de tickets, y cómo las decisiones de flujo de trabajo (por ejemplo, squash merges, pairing, sin PR) moldean lo que siquiera significa un “buen” mensaje de commit.
Con qué frecuencia se usa el historial de commits
- Las experiencias divergen mucho. Algunas personas dicen que casi nunca leen mensajes antiguos de commit en años de trabajo; otras informan que usan el historial o
blamesemanalmente o incluso a diario. - Usos comunes: depuración (“¿por qué este código es así?”), rastrear cuándo cambió el comportamiento, hacer
bisectpara regresiones y entender el impacto en líneas o archivos concretos. - Varios argumentan que los mensajes rara vez añaden más que el diff y que a menudo son de baja calidad (“wip”, “update”), lo que desincentiva depender de ellos.
Qué deberían contener los buenos mensajes de commit
- Muchos quieren que los mensajes de commit capturen el “por qué” y el “qué” de alto nivel, dejando que el diff proporcione el “cómo” detallado.
- Un asunto corto y fácil de escanear, más un cuerpo detallado opcional, es un patrón ampliamente apreciado.
- Algunos ven los mensajes de commit sobre todo como trabajo intermedio para sí mismos; otros, como documentación compartida a largo plazo y fuente de changelog.
- La coherencia dentro del equipo suele considerarse más importante que cualquier estilo en particular.
Estilo con el sujeto primero frente al estilo con el verbo primero
- A favor del sujeto primero: poner primero la parte más variable/importante (el sujeto o componente afectado) supuestamente mejora el escaneo, de forma similar al diseño de listas y a las conclusiones de seguimiento ocular.
- Los críticos cuestionan tanto la legibilidad como el supuesto respaldo psicológico, y argumentan que lo que importa son los verbos/acciones (“qué cambió”) y que los ejemplos son demasiado vagos.
- Algunos prefieren formatos con prefijo de componente o
conventional commits(type(scope): summary), que categorizan los cambios y facilitan las herramientas.
Mensajes de commit frente a tickets y otros artefactos
- Muchos enfatizan incluir IDs de ticket para enlazar con contexto empresarial y de discusión más rico; otros no quieren IDs en los títulos y prefieren ponerlos en el cuerpo o en trailers.
- Varios advierten que los sistemas de tickets y las URLs cambian o desaparecen, lo que vuelve frágiles los IDs o enlaces que dependen solo del commit; defienden explicaciones de commit autocontenidas.
- Un equipo describe un método más amplio: sin pull requests, mucho pairing/mobbing, trabajo con archivos de texto y registros de equipos en git, y mensajes de commit principalmente como índices concisos con sujeto primero.
Meta: valor y discusiones triviales
- Algunos ven los debates sobre el estilo de los commits como discusiones triviales de bajo retorno frente a los problemas del producto.
- Otros argumentan que los malos mensajes causan una pérdida de tiempo significativa a largo plazo y que una disciplina modesta aquí compensa.