Conventional Commits: cuándo estorban de verdad

Hay una razón por la que Conventional Commits se volvió popular: promete orden. Si todos escriben los commits con el mismo formato, puedes automatizar changelogs, versionado semántico y parte del trabajo de release. En equipos pequeños, eso suena razonable. En equipos grandes, parece casi obligatorio.

El problema aparece cuando la convención deja de ser una ayuda y se convierte en una tarea más que tienes que “cumplir” antes de terminar el día. Ahí ya no estás optimizando el flujo de trabajo. Estás entrenando a la gente para pensar en el formato del mensaje antes que en el cambio que realmente importa.

Qué resuelve Conventional Commits y por qué seduce tanto

Conventional Commits define una estructura predecible para los mensajes de Git, algo como feat:, fix: o chore: seguido de una descripción breve. La especificación oficial está bien documentada y su objetivo es claro: que las herramientas puedan leer tus commits sin adivinar qué hiciste. Puedes revisarla en la documentación del proyecto: https://www.conventionalcommits.org/en/v1.0.0/.

Eso tiene ventajas concretas. Si tu equipo publica paquetes, genera notas de versión o necesita saber si un commit rompe compatibilidad, el formato ayuda. También reduce ambigüedad en repositorios con mucha actividad. Un fix: no es lo mismo que un refactor: y una máquina sí puede distinguirlos sin cansarse.

El problema es que una buena idea técnica suele venderse como una buena idea universal. Y no lo es. Que algo funcione muy bien para automatización no significa que deba imponerse como ritual diario para cualquier equipo, proyecto o tamaño de organización.

La promesa real: automatización, no disciplina moral

La parte más útil de Conventional Commits no es que te haga escribir “mejores” mensajes. Es que le da al sistema una señal estructurada. Si usas semantic-release, Changesets o pipelines parecidos, la convención permite inferir versiones y notas sin que alguien revise cada commit a mano.

Eso es útil cuando la automatización te ahorra tiempo medible. Por ejemplo, si tu equipo hace 12 releases al mes y cada release manual toma 20 minutos entre revisar commits, escribir notas y validar bumps, estás gastando unas 4 horas mensuales solo en coordinación. Si la convención reduce eso a 30 minutos, sí hay valor.

Pero si no estás usando ninguna automatización, o si tu release ya se hace por PR, tags o pipelines más simples, el beneficio baja mucho. En ese caso, el costo de obligar a todo el equipo a seguir la convención puede ser mayor que el ahorro que genera.

Cuándo empieza a estorbar de verdad

La fricción no aparece el primer día. Aparece cuando el equipo ya entendió la regla y aun así tiene que detenerse para decidir si un cambio es feat, fix, refactor o chore. Ese microtiempo no parece grave. Sumado en 30 commits al día, sí lo es.

También estorba cuando el mensaje deja de servirle al humano y solo le sirve a la herramienta. Un buen commit debería ayudar a alguien a entender el contexto dentro de seis meses. Si el equipo termina escribiendo mensajes como chore: update dependencies para todo, el formato existe, pero la información útil desaparece.

Otro punto delicado es la carga mental. Cada regla extra compite con una tarea que ya consume atención: revisar tests, leer diffs, validar comportamiento, coordinar con QA o con producto. Si la convención se vuelve una puerta más antes de terminar, el equipo empieza a verla como burocracia.

Señales de que ya cruzaste la línea

Estas señales suelen aparecer juntas:

1. La discusión sobre el commit toma más tiempo que el cambio en sí.
2. La gente abre el editor de mensajes y duda entre dos o tres tipos.
3. Se hacen squash merges, así que el detalle del commit individual casi nunca se usa.
4. El historial está lleno de commits “correctos” pero poco útiles para depurar o auditar.
5. Los nuevos integrantes preguntan más por la regla que por la arquitectura.

Si te suena familiar, no significa que debas eliminar la convención mañana. Significa que ya no está sirviendo al objetivo original. Y cuando una regla deja de ahorrar tiempo, conviene medirla como cualquier otra decisión de ingeniería.

El costo oculto: tiempo, contexto y decisiones pequeñas

Hay un costo que suele subestimarse: la suma de decisiones pequeñas. Decidir si un cambio es feat o fix parece trivial. Pero si lo haces decenas de veces por semana, el equipo convierte una acción mecánica en una serie de mini debates.

Pensemos en un equipo de 8 personas que hace 15 commits por día entre todos. Si cada commit agrega solo 20 segundos de fricción para decidir el tipo, escribir el prefijo o corregirlo, estás consumiendo 5 minutos diarios. En un mes laboral de 22 días, son casi 2 horas. No parece mucho hasta que recuerdas que ese tiempo no genera producto, no reduce bugs y no mejora la experiencia del usuario.

La otra parte del costo es el contexto perdido. Cuando la convención domina el mensaje, mucha gente deja de escribir por qué hizo el cambio. Y ahí el historial deja de responder preguntas útiles como: ¿por qué se cambió esta validación?, ¿qué problema de cliente resolvía?, ¿qué alternativa se descartó?

Tabla: cuándo aporta y cuándo frena

La tabla no dice que la convención sea mala. Dice algo más útil: su valor depende del flujo real. Si el flujo no necesita la señal estructurada, el formato empieza a ser una carga.

Cuándo sí tiene sentido mantenerla

Conviene ser justo: Conventional Commits no es un capricho sin utilidad. Hay contextos donde sí mejora el trabajo diario. Si mantienes paquetes versionados con semver, publicas varias veces por semana y quieres changelogs consistentes, la convención te ahorra pasos.

También funciona bien cuando el equipo es disciplinado y el historial de Git se usa de verdad. Por ejemplo, si haces revisiones de incidentes, depuras regresiones con git bisect o quieres entender rápidamente qué commits fueron cambios funcionales y cuáles fueron tareas de mantenimiento, la estructura ayuda.

El punto no es “usar o no usar” como si fuera una religión. El punto es preguntarte si el beneficio ocurre en tu proceso real. Si tu equipo ya usa PR bien descritas, tickets claros y releases automáticas desde tags, quizá el commit message no necesita cargar con toda la responsabilidad.

Cuándo la automatización sí compensa

Hay tres casos donde la convención suele pagar su costo:

• Publicas paquetes o librerías y necesitas versionado automático.
• Generas notas de versión para clientes, QA o soporte.
• Quieres que bots o scripts clasifiquen cambios sin intervención humana.

En esos escenarios, el formato deja de ser un adorno y se convierte en una interfaz. Y como toda interfaz, debe optimizarse por utilidad, no por pureza.

Si quieres revisar cómo se usa en herramientas reales, la documentación de semantic-release explica bien el vínculo entre commits y versionado: https://semantic-release.gitbook.io/semantic-release/.

Qué hacer si tu equipo ya está cansado de la regla

No necesitas hacer una migración dramática. De hecho, las mejores decisiones de proceso suelen ser reversibles y pequeñas. Puedes empezar midiendo cuánto valor real obtiene el equipo de la convención durante un mes.

Una forma simple de evaluarlo es esta:

1. Revisa cuántas veces al mes alguien usa el historial de commits para algo concreto.
2. Cuenta cuántos commits terminan corregidos por formato o por tipo incorrecto.
3. Estima cuánto tiempo toma esa corrección por persona.
4. Pregunta si el changelog automatizado se usa de verdad o solo “está bonito”.
5. Decide si el beneficio supera la fricción en tu flujo actual.

Si la respuesta es no, no hace falta eliminar toda estructura. Puedes relajar la regla: aceptar Conventional Commits solo en repositorios que publican artefactos, o pedirlo en ramas de release y no en todo el trabajo diario.

Alternativas menos pesadas

Hay opciones intermedias que funcionan bien:

• Mensajes libres, pero con una plantilla mínima: qué cambió y por qué.
• Convención solo para commits que llegan a main, no para cada commit local.
• Reglas en PR en lugar de reglas en Git.
• Automatización por etiquetas, releases o títulos de PR, no por commit individual.

Estas alternativas reducen la fricción sin perder trazabilidad. Y para muchos equipos, eso es suficiente.

Productividad real: menos ritual, más señal útil

La productividad de un equipo de software no se mide por cuántas reglas sigue, sino por cuántas decisiones innecesarias elimina. Si una convención te ayuda a automatizar, perfecto. Si te obliga a discutir detalles que no cambian el resultado, ya está ocupando espacio mental que podrías dedicar a diseño, calidad o entrega.

Esto vale especialmente en equipos latinoamericanos donde el tiempo de coordinación ya compite con reuniones, soporte, rotación y contextos muy distintos entre personas. Si tu proceso agrega fricción sin aportar un retorno claro, el costo no es teórico. Se siente en cada commit, cada revisión y cada release.

La pregunta correcta no es si Conventional Commits está bien o mal. La pregunta es más simple: ¿te está ayudando a entregar mejor o solo te está dando la sensación de orden? Si no puedes responder con un caso real, un número o una automatización concreta, probablemente ya estás pagando más de lo que recibes.

Tabla resumen