Conventional Commits se ha consolidado como uno de los estándares de formato de mensajes de commit más extendidos en el desarrollo de software. Proyectos populares como Angular, Electron, freeCodeCamp, Vite, Nuxt o Jenkins X lo adoptan en sus guías de contribución. Sin embargo, un artículo crítico sostiene que se trata de un estándar "activamente malo" porque dirige la atención hacia lo equivocado y no cumple sus promesas.
El principal problema, según el autor, es de enfoque. El formato convencional obliga a anteponer el tipo de cambio (fix, feat, chore, docs, refactor) al alcance o scope, que es opcional. Esto es, a su juicio, exactamente al revés de lo útil. Los distintos perfiles que consultan el historial de un repositorio —colaboradores que se ponen al día, desarrolladores depurando un bug o equipos respondiendo a una incidencia en producción— necesitan localizar el área del código afectada, no la categoría del cambio. Un commit sin scope equivale, dice, a una oración sin sujeto. Además, el tipo suele ser redundante: en la mayoría de los casos la propia descripción ya revela si se trata de una corrección, una refactorización o una nueva funcionalidad. Y en otros resulta restrictivo, porque un mismo commit puede ser a la vez bugfix, refactor y feature, como ocurre con una actualización que añade compatibilidad con un estándar web emergente.
La segunda crítica apunta a las supuestas ventajas del estándar. La primera, la generación automática de changelogs con herramientas como git-cliff o conventional-changelog, parte de una premisa errónea: el público del changelog (usuarios finales) y el del historial de commits (desarrolladores) son distintos y buscan información diferente. Un changelog describe diferencias funcionales entre versiones; un registro de commits narra la evolución técnica del código. Mezclarlos produce resultados mediocres, y los reverts ilustran bien el problema: para el desarrollador el revert forma parte de la historia, para el usuario equivale a un cambio que nunca existió.
La segunda ventaja, determinar automáticamente el salto de versión semántica a partir de los tipos de commit, también se quiebra en la práctica. Situaciones como reverts, correcciones que introducen nuevos cambios incompatibles o hotfixes urgentes rompen la lógica determinista del estándar.
En conjunto, el artículo concluye que Conventional Commits es un estándar contraproducente: fomenta convenciones que ni ayudan a quien lee el historial ni permiten automatizar de forma fiable lo que promete.