Deja de usar Conventional Commits

(sumnerevans.com)

4 puntos por GN⁺ 2026-06-06 | 2 comentarios | Compartir por WhatsApp

Conventional Commits intenta dar significado a los mensajes de commit con el formato <type>[optional scope]: <description>, pero pone primero el tipo de cambio y deja el alcance como opcional, desplazando al final la información realmente necesaria para explorar el historial
Quienes contribuyen, depuran o responden a incidentes buscan en el log de commits qué área de código fue tocada, y como los bugs pueden surgir en cualquier tipo de cambio, el scope es más importante que el tipo
En casos como fix(compiler): prevent namespaced SVG <style> elements from being stripped, la naturaleza de corrección de bug ya se entiende por la descripción, y en casos como refactor(core): Update webmcp support to use document.modelContext, un solo commit puede abarcar corrección, refactorización y nueva funcionalidad, por lo que el type es redundante y limitado
La generación automática de CHANGELOG y la decisión de aumentar versiones semánticas fallan porque los lectores del log de commits y del changelog son distintos, y porque los reverts, las rupturas accidentales de compatibilidad y su resolución posterior pueden desalinear el resultado
Los mensajes de commit con prefijo de scope muestran primero el sujeto del cambio, y también conviene basar las condiciones de build y despliegue en los archivos modificados vía git diff, no en el tipo del título

Prioridades equivocadas

Conventional Commits tiene como objetivo dar significado a los mensajes de commit para ayudar tanto a desarrolladores como a usuarios finales a entender los cambios

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

La línea de título se compone de un <type> como fix, feat, chore, docs, refactor, un scope opcional y una descripción
Su defecto principal es que prioriza el tipo de cambio sobre el scope, que es el verdadero sujeto del cambio
Hacer opcional el scope permite que falte la información más importante de un commit, y poner el type al inicio del título invierte las prioridades

Por qué el scope importa más que el type

Quienes contribuyen leen el log de commits para encontrar cambios desde su última contribución, seguir el flujo general del proyecto y detectar commits que podrían entrar en conflicto con el trabajo en curso al hacer pull o rebase
Quienes depuran buscan cambios que hayan tocado áreas relacionadas con el componente donde apareció el bug, y como un bug puede surgir en cualquier tipo de cambio, la información de type no ayuda
Quienes responden a incidentes revisan el log alrededor del momento de la falla para ubicar el área que pudo causarla; si en el punto donde se disparan los errores del API de entrada aparece un commit con scope auth, se vuelve un candidato fuerte
Para quien lee el log de commits, lo importante no es qué clase de cambio fue, sino qué área tocó

La redundancia y las limitaciones del type

fix(compiler): prevent namespaced SVG <style> elements from being stripped ya deja claro por la descripción que se trata de una corrección de bug, así que el type fix es redundante
El espacio en la línea de título de un commit es limitado, así que gastar caracteres en un type que ya puede inferirse de la descripción no aporta mucho
refactor(core): Update webmcp support to use document.modelContext actualiza la funcionalidad webmcp del componente core para soportar tanto document.modelContext como navigator.modelContext
Ese cambio puede verse al mismo tiempo como corrección de bug, refactorización y nueva funcionalidad, pero la información realmente importante es que afecta al componente core/webmcp

Los límites de la promesa de automatización

La idea de generar automáticamente un CHANGELOG a partir de commits con herramientas como git-cliff o conventional-changelog tiene el problema de que el log de commits y el changelog tienen lectores distintos
El CHANGELOG está dirigido a usuarios y se enfoca en entender las diferencias funcionales y de negocio entre versiones
El log de commits está dirigido a desarrolladores y se enfoca en cómo cambia el codebase con el tiempo y en leer ese flujo desde la perspectiva del scope
En proyectos de complejidad media o superior, una sola funcionalidad significativa suele entrar a través de varios commits; para el desarrollador, el proceso de implementación es útil, pero para el usuario final solo importa la nueva funcionalidad como resultado
Los commits de revert son importantes para los desarrolladores dentro del flujo del historial, pero para el usuario final un cambio revertido equivale a un cambio que nunca existió
Incrementar versiones semánticas según el type del commit puede llevar a subir la versión major aunque el cambio rompedor se haya revertido, a subir mal como minor o patch si la ruptura se detecta después, o a considerarlo rompedor aunque el problema desaparezca al combinarse con commits posteriores
En estas situaciones se puede corregir el historial con rebase, pero el flujo de trabajo puede impedirlo o romperlo, y eso reduce la confiabilidad del flujo que transmite el log de commits
Si los procesos de build o despliegue se activan por el type del título del commit, se pueden esquivar las herramientas automáticas con algo como un commit titulado docs: fix typos que en realidad introduce una vulnerabilidad en el subsistema de autenticación
Es mejor decidir las condiciones de build y despliegue identificando los archivos modificados con git diff que basándose en el título del commit

Problemas de adopción y alternativa

Conventional Commits propone que cada proyecto defina su propio conjunto de types, pero muchos proyectos simplemente adoptan los types por defecto de commitlint, que pueden no encajar bien con las características particulares de cada proyecto
La especificación de Conventional Commits técnicamente solo define fix y feat, y deja los demás types a criterio del proyecto
En entornos corporativos, a veces los requisitos de gestión de cambios y auditoría obligan a incluir un número de ticket en cada mensaje de commit; si <scope> se usa para ese ticket, se pierde metadata útil
Linux, FreeBSD, Git, Go, NixOS y Node.js usan mensajes de commit con prefijo de scope adaptados a cada proyecto

Proyecto	Formato	Ejemplo
Linux	`subsystem: description`	`i2c: virtio: mark device ready before registering the adapter`
FreeBSD	`prefix: Description`	`linuxulator: Return EINVAL for invalid inotify flags`
Git	`area: description`	`gitlab-ci: update macOS image`
Go	`package: description`	`net/http/cookiejar: add godoc links`
nixpkgs	`pkg-name: description`	`xwayland: 24.1.11 -> 24.1.12`
Node.js	`subsystem: description`	`stream: fast-path stateless transform flush results`

En el kernel de Linux, el subsystem; en el proyecto Go, la ruta del package; y en una arquitectura de microservicios, el nombre del microservicio, suelen ser scopes naturales
scopedcommits.com plantea volver a un formato de mensajes de commit centrado en el scope y separar la generación del CHANGELOG de la gestión del log de commits
Las ventajas de Conventional Commits no se tradujeron en beneficios reales, y su popularidad en proyectos open source, junto con la tendencia de la IA a elegirlo por defecto, ha propagado mensajes de commit con antipatrones mezclados

2 comentarios

GN⁺ 2026-06-07

Comentarios de Hacker News

Parece que los programadores siempre terminan discutiendo y quejándose hasta de detalles triviales como tabs vs. espacios para decidir cuál es la configuración óptima
Eso no significa que Conventional Commits sea la mejor opción casi como una revelación divina para estructurar mensajes de commit, pero sí creo que tener una estructura definida y alinear las expectativas sobre los mensajes de commit es mucho más efectivo e importante
El autor le da mucha importancia a que el alcance es más importante que el tipo, pero no me parece que la diferencia entre fix(compiler) y compiler fix sea algo por lo que valga la pena rasgarse las vestiduras
En la industria tecnológica hay muchas cosas que se volvieron estándar aunque no sean óptimas; por ejemplo, mucha gente diría que si hoy rehiciéramos JSON desde cero debería soportar comentarios, formatos numéricos más claros, etc.
Aun así, se volvió estándar porque era mejor que lo anterior en varios contextos, y aunque puede existir un formato mejor y un poco distinto a Conventional Commits, no parece lo bastante mejor como para justificar otro esquema competidor para estructurar mensajes de commit
- Una estructura definida no equivale a calidad
  Un mensaje de commit puede ser excelente aun con una estructura flexible si transmite bien la naturaleza del cambio, y al revés, puede ser muy estructurado pero confuso o vacío de información
  En general coincido con el autor: Conventional Commits no resuelve el problema central de los malos mensajes de commit
- Estoy a favor de la estandarización, pero con esa lógica también se puede seguir justificando cualquier statu quo subóptimo
  XML es suficientemente bueno y es un estándar; SOAP es suficientemente bueno y es un estándar
  Decir que Conventional Commits es suficientemente bueno y está suficientemente estandarizado como para que no valga la pena considerar otra estructura hace que ese “vale la pena” sea algo subjetivo
  Si haces commits y lees PRs todos los días, incluso la pequeña fricción que genera el formato de Conventional Commits puede acumularse, y no verlo como una ley natural sino dejar otras opciones puede ayudar a los equipos que las prefieren
  De todos modos, la mayoría de los equipos ni siquiera generan changelogs
- No tengo un interés especial en esta discusión, pero la réplica del artículo original me suena vacía
  Es cierto que el alcance importa, pero siento que eso se puede inferir del contenido del commit
  Al revisar un diff, ver las rutas que se tocaron es una verificación de sanidad importante, y un diff de “test” no debería modificar código de autenticación de producción
  Aun así, si quieres verlo en --oneline, me parece que feat(auth): es mejor que feat:
  No estoy de acuerdo con la afirmación de que la audiencia objetivo está equivocada
  Un commit feat realmente debería explicar un cambio desde la perspectiva del producto, y conviene ordenar las cosas apilando primero buenos cambios de refactorización sin significado funcional y luego poner encima un pequeño cambio de funcionalidad nueva
  Eso también es lo más útil para incluir en la explicación del diff, y el contexto técnico como “por qué se eligió el algoritmo X” debería ponerse en comentarios o en DECISIONS.md para no perderlo
  En una empresa que se mueve rápido, probablemente solo la gente obsesiva se ocupa de ese tipo de tareas tediosas en el historial de commits, pero en proyectos open source me parece mucho más importante dejar ese contexto escondido en los mensajes de commit
- El punto central no es que el alcance sea más importante que el tipo, sino que el lenguaje natural puede expresar y enfatizar lo que uno considera importante, mientras que si metes todo en un formato específico esa información se pierde
  Hay una razón por la que existen formatos como Markdown y texto plano, y no solo JSON
- Me parece que Conventional Commits es una buena idea porque, con herramientas, se puede obligar a la gente a poner al menos un mínimo de reflexión en sus mensajes de commit
  He revisado demasiados commits cuyo título era small fix cuando en realidad no eran para nada cambios pequeños
La verdadera conclusión es que los requisitos son distintos en cada proyecto
Después de más de 30 años usando control de código fuente, nunca he hecho un trabajo en el que fuera útil meter el componente en la descripción de una forma estandarizada (en el artículo lo llaman scope)
Con solo ver en qué parte del árbol de código fuente están los archivos afectados, ya queda claro qué componente cambió, y bug, fix y feature tampoco aportan un valor útil
Si no hubiera sido importante, no se habría hecho el check-in
Lo único que me ha parecido útil es algo que el artículo ni siquiera toca: el enlace o ID de la solicitud de cambio relacionada
El commit ya contiene información sobre qué cambió, y lo que falta es el contexto de por qué cambió
Incluso en proyectos personales pongo una referencia de JIRA entre corchetes al inicio de la descripción, y aunque sea algo que decidí corregir de paso durante el desarrollo, creo un JIRA corto de una sola línea para obtener un ID y anotar ahí la razón
- El “por qué” es exactamente lo que debe ir en el mensaje de commit de git
  Capturar el “por qué” es el propósito completo de ese mensaje, y pegar un enlace a un recurso externo que algún día puede desaparecer no es un buen sustituto
- Cuando usábamos JIRA, nosotros también lo hacíamos así
  Si es un issue de GitHub, desde el commit puedes volver a la discusión del PR, y ese PR debería tener el issue vinculado y otros punteros
  Claro, al pasarnos a GitHub Issues casi abandonamos JIRA, y unos años después la instancia se apagó y se eliminó
  Ahora todas esas etiquetas de JIRA ya no sirven para nada
  Por eso más bien creo que hace falta un acoplamiento fuerte entre el issue tracker y el repositorio git
  Lo que de verdad quieres es portabilidad, pero no sé cómo conseguirla sin ese acoplamiento fuerte
  Idealmente debería existir un formato estándar abierto, pero en la práctica GitHub es el gorila gigantesco que define el formato, y si clones como GitLab pueden importar los metadatos del proyecto de GitHub o al menos los PR, en la práctica eso se acerca bastante
  En cualquier caso, no es una buena política dejar punteros fijos e inmutables a productos de Atlassian que quizá ni uses dentro de 5 años
  Preferiría aceptar una política donde el commit de git deba sostenerse completamente por sí solo y toda la información sobre el “por qué” del cambio quede integrada en el mensaje de commit o en comentarios del código fuente
  Aun así, creo que eso también falla, porque la gente escribe demasiado poco en los commits de git y pierde información al resumir el issue, mientras que el ida y vuelta de la discusión en el PR contiene más que un resumen de la razón del cambio en una sola voz, y por eso resulta útil
- Es útil si haces generación automática de notas de lanzamiento
  Si agrupas primero las funciones nuevas y luego las correcciones de errores, a los usuarios no técnicos les queda un poco más fácil de leer
- Sí
  Los mensajes de commit no son para generar changelogs, sino para los desarrolladores del futuro
  El momento principal en que ese desarrollador lee el mensaje de commit es cuando no entiende por qué existe ese commit
  No se pregunta qué cambió, sino cuál es el propósito de cierta línea
  Entonces ejecuta blame, mira el commit, el desarrollador original ya se fue de la empresa, el JIRA antiguo puede haber desaparecido, y la única pista es el mensaje de commit
  https://dev.to/splix/the-why-behind-the-code-2bb1
- Me pregunto si la ventaja de usar una fuente aparte es que puedes meter cosas como imágenes, o si me estoy perdiendo algo
  ¿No basta con poner el contexto en el cuerpo del commit?
La palabra chore de mucha gente que usa Conventional Commits siempre me ha molestado
Personalmente, también aquí por suerte se menciona el estilo de títulos de commit del kernel de Linux, que he preferido desde hace tiempo
[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
- Totalmente de acuerdo
  La actitud que implica chore me resulta muy desagradable
  Hace sentir como si todo lo demás tuviera que marcarse como fun o indifferent, y ese tipo de juicio emocional no tiene nada que hacer en un mensaje de commit
- Encontré una alternativa: upkeep
  Significa más o menos lo mismo, pero sin el matiz despectivo
- También podría gustarte el artículo de Rich: https://richvdh.org/conventional-commits-considered-harmful....
- Es cierto que la terminología es mala
  Además, también finge que conoces de antemano el impacto total del commit, cuando en realidad no lo sabes
  Una vez que aparecen Conventional Commits, tanto tus compañeros de equipo como los LLM tienen que gastar tiempo y tokens inventando esa nomenclatura tonta
Mi principal queja sobre Conventional Commits era que el título del commit no incluye el número del issue
Ni siquiera se menciona en la especificación como algo opcional
Para mí, es casi la información más importante en un mensaje de commit
No sé cuántas veces en los últimos 15 años he contrastado la descripción del issue referenciado por un commit viejo para entender el contexto completo del cambio
Sentía que este hábito era una especie de estándar, pero no fue hasta que conocí Conventional Commits que aprendí que no lo era
Nunca entendí por qué se volvió popular
- Personalmente prefiero poner el issue como git trailer
  fix thing in foo
  
  Issue: ABC-123

Git tiene muchas funciones integradas para parsear y dar formato a este tipo de trailers, así que es fácil crear un alias personalizado de git log para verlos en línea o parsearlos en CI

Si ya estás revisando un changelog con límite de caracteres, no me interesa mucho que el mensaje principal del commit tenga XYZ-999999
Está bien etiquetarlo con un trailer, pero me interesa mucho más ver qué hizo el commit que el número de issue de Jira
Solo lo veo como un problema cuando se exige que la clave del issue vaya obligatoriamente al principio del título
Incluso eso me parece malo para la legibilidad
No veo por qué no se puede poner simplemente en alguna parte después del formato misceláneo de Conventional Commits
La clave del issue debería poder extraerse con una expresión regular como un prefijo alfanumérico seguido de números, así que casi no hay necesidad de que este “estándar” reserve un espacio aparte para eso
Personalmente, sin Conventional Commits, si el commit está relacionado con ese issue lo pongo al final entre paréntesis
Si la relación es más fuerte, como cuando corrige el issue, también agrego un trailer Fixes en el mensaje
Qué interesante
Nosotros hasta ahora hemos usado algo como fix(ABC-123): some message here, y se enlaza bien además de renderizarse muy bien en las notas de versión automáticas
Eso no es un estándar sino una convención
Basta con definir dentro del equipo una regla para incluir el ID del ticket en el mensaje del commit
Si quieres que sea legible para máquinas, usa un footer/trailer
No tengo nada bueno que decir sobre Conventional Commits
El formato ocupa espacio en la parte del mensaje que más se lee, y la categoría o el tipo aportan poca información
Se puede reemplazar poniendo un verbo honesto en inglés en el título como una oración, y una oración se lee mucho mejor que tres tipos de signos de puntuación como :, () y !
Más o menos tolero que haya un “ámbito” en el título, y eso también existía antes que esta convención
En el trabajo hacemos una webapp para usuarios no técnicos, y para el changelog dirigido a esos usuarios se puede escribir perfectamente en noruego
Los mensajes de commit no le importan al usuario, y exigir que todos los commits sean lo bastante buenos como para entrar en el changelog final para usuarios es algo que, en nuestro caso, no va a pasar pronto
En cambio, se pueden usar footer/trailer
Donde Conventional Commits realmente ayuda es en el despliegue continuo
Cada vez que se hace merge a main, se puede asignar automáticamente una etiqueta SemVer y desplegar, porque las decisiones necesarias para el etiquetado y el versionado ya las tomó el desarrollador al escribir el mensaje del commit
Admito totalmente que no encaja en proyectos enormes como Linux kernel
Pero en el 99% de los proyectos, combinar Conventional Commits con SemVer mejora mucho el proceso de release actual y facilita la automatización
- Incluso en un contexto de despliegue continuo, prefiero un enfoque que dependa de git tags
  git describe muchas veces es suficiente para el versionado en despliegue continuo, y v1.2.3-4-gabcdef describe el commit con la precisión suficiente para Git, mientras se parece a SemVer y ayuda a establecer expectativas
  Esto aplica especialmente cuando solo se agregan nuevos git tags por criterio humano, por ejemplo, cuando se decide que este sí es un cambio rompiente y que ahora hay que marcar una nueva versión major
  En números de versión con formato git describe, la única discusión real suele ser si cambiar el primer guion por un signo más para ajustarse mejor a las expectativas de SemVer, y si vale la pena forzar esas expectativas, como ordenar correctamente las versiones en un gestor de paquetes, se puede convertir con una expresión regular sencilla
  git describe facilita la automatización de CD, pero permite dejar la decisión del número de versión en manos de personas mediante la elección de git tag o GitHub Releases, en lugar de adivinarla a partir de palabras mágicas en el historial de commits
- En mi proyecto open source uso este método para automatizar los incrementos de SemVer y funciona muy bien
  En el trabajo también exigimos “tags” según a quién le interesen los cambios
  Aquí tag no significa git tag, sino una cadena dentro del título del PR, y con base en ese “tag” generamos changelogs para cada equipo
- El artículo explica por qué eso no funciona bien
- Pero ¿por qué tiene que ir eso en el título?
  Si quieres versionar de esa manera tan rara, puedes poner una frase mágica en el cuerpo del commit
  Así tampoco quedas limitado a una sola palabra
Me desagrada bastante este estilo de títulos
Parece que expresiones como “Stop something” son muy populares, pero suenan imperativas y transmiten una sensación de “yo definitivamente tengo la razón”
No sé por qué no lo escriben como “In favour of something” o “A case against something”
- No entiendo por qué no se puede defender claramente y de forma directa la postura que uno prefiere
  No hace falta estar de acuerdo con esa postura, pero pedir que se suavice la expresión me parece una respuesta débil
- No es tan malo como considered harmful, pero igual tiene un toque tóxico
  La idea parece ser hacer que una preferencia personal arbitraria, como querer invertir el orden de A y B, se vea más importante de lo que realmente es
- Cuando una afirmación desafía nuestra visión del mundo, genera más interés
  Para mucha gente eso es grosero, pero la economía de la atención recompensa ese tipo de cosas
  Edit: parece que cambiaron el título por uno menos provocador
  Bien hecho
- Vine a decir algo parecido
  No me gustan mucho los Conventional Commits, pero hay que dejar que cada quien use lo que quiera
- https://knowyourmeme.com/memes/stop-doing-math
  Hay un meme que influyó en parte de este género de títulos
Qué raro
La razón principal para usar este estilo de mensajes de commit es la automatización de CI/CD
Edit: no vi esa parte en el artículo la primera vez que lo leí, pero sí la cubrían
Perdón
Los tipos de commit van al principio porque le indican a los flujos de trabajo automatizados cómo procesar el commit
Por ejemplo, si haces CD, cuando solo hay varios commits fix: , solo aumenta el número de parche del versionado semántico
Si haces un commit feat: , sube la versión menor, y feat! implica un aumento de versión mayor
Incluso si no usas CD para los releases, los mensajes de commit semánticos también se usan para automatizar la generación del changelog
Claro, normalmente no deberías poner los mensajes de commit de Git tal cual en el changelog
Esos mensajes están dirigidos a los desarrolladores, no a los usuarios
- El artículo trata esos dos puntos con bastante claridad
  El versionado semántico se rompe con los rollbacks, y los changelogs automáticos tienen el público objetivo equivocado
- He usado este estilo para subir versiones y me gustó, así que me habría gustado que el artículo propusiera una alternativa que sí funcionara
  Hoy uso CalVer en lugar de SemVer, así que ya no es un problema, pero la idea de un aumento automático e inteligente de versión me gusta
- Entonces, ¿qué convención se usaría en los git trailers?
  Aunque el título del commit tenga fix o feat, eso no aporta información útil para quien está revisando el log
- No, no
  Se trata de eliminar Conventional Commits para que la IA pueda hacer commits más fácilmente
Si inviertes el orden, en realidad se resuelve mi molestia principal
¿Qué demonios es una feature?
refactor(core): Update webmcp support to use document.modelContext

Como dice el autor, la frontera entre arreglo, mejora y limpieza general es difusa, y dividir cada cambio semántico en commits separados de todos modos puede terminar en un squash después, así que solo crea trabajo que no beneficia a nadie
Veo Conventional Commits como un subproducto de intentar automatizar SemVer, más que como algo que resuelva directamente otros problemas
De todos modos, no creo que los changelogs deban automatizarse
Si necesitas una lista, puedes ver git log
Un changelog es una oportunidad para comunicar a un público más amplio lo que realmente pasó internamente
“El lector del changelog es completamente distinto del lector del commit log”
“El changelog está dirigido a los usuarios”

Siento que ese barco ya zarpó
La mayoría de las empresas se conforman con “Bug Fixes & Performance Improvements”
Al menos, si no van a poner esfuerzo, un changelog generado es mejor que no tener ninguno
- En software con autoactualización semanal, lo mejor que he usado fue anteponer uv: a los commits visibles para el usuario
  Luego cada semana los buscábamos y usábamos el texto tal cual o lo retocábamos un poco
  También lo poníamos en el menú de Help/Release-notes del producto
  Es un poco gracioso que me digan que deje de hacer algo que ni hago ni he oído que alguien haga
  Normalmente solo se usan prefijos especiales para migraciones de esquema de base de datos u otras cosas importantes
- Está confundiendo changelog con release notes
  Parece que también pone mal los nombres a los commits, y probablemente también a los símbolos
  Es un problema de habilidad, pero como se está lamentando en público, mejor dejarlo pasar

GN⁺ 2026-06-06

Opiniones en Lobste.rs

Me da gusto ver un texto que ordena lógicamente la crítica a conventional commits en vez de quedarse en un rechazo instintivo.
Nunca me había detenido a pensar a fondo por qué no me gustaban, y supongo que fue porque empecé a asociarlos con el código generado por LLM. En particular, lo que más odio es chore:; ojalá no volviéramos a inventar la notación húngara. Nunca debió haberse creado
- En especial, chore: ya ni siquiera existe en la guía de estilo de commits de Angular y, al parecer, al darse cuenta de lo ambiguo que era, lo absorbieron en build:
  Incluso cuando todavía estaba en el estilo de Angular, la descripción de chore: proponía usos bastante específicos, pero en algunos proyectos de código abierto parece que se lo ponen por inercia a tareas que literalmente se sienten como algo fastidioso de hacer
No me encantan los conventional commits, pero creo que la alternativa propuesta pasa por alto por qué el scope es opcional
En proyectos pequeños que no tienen muchos módulos claramente definidos, el concepto de “scope” no resulta muy útil. Una práctica útil que ambos omiten es incluir números de issues o tickets en el título del commit; eso facilita entender el contexto adicional del cambio y ayuda especialmente durante la revisión de código. Eso sí, no me gusta volver obligatorio el número de ticket, porque termina generando tickets inútiles para cambios triviales, pero si un cambio resuelve un bug o una tarea específica, debería estar vinculado con ese bug o esa tarea
- Si no hace falta un scope, simplemente se omite
  Sigue siendo mejor que un “type” de commit redundante que debería quedar claro con solo ver la línea de título
- En el mejor de los casos, no debería haber ningún estilo de commit reglamentado, y simplemente habría que usar la forma de expresión que encaje con cada commit
  Si el cambio corresponde claramente a un ticket, se usa un commit con “número de ticket”; si no, se usa otra forma. Algunos cambios encajan bien con el type pero menos con el scope, y al revés, así que también se pueden mezclar scoped commits y conventional commits
Quiero decir: “no usen tipografía monoespaciada en el texto de los párrafos”
Aun así, en general estoy de acuerdo con la premisa del artículo
Aunque los mensajes de commit no sean muy buenos, para darse una idea del alcance de los cambios recomiendo usar seguido git log --name-only o git log --stat
Ver los nombres de archivos ayuda bastante a entender qué cambió sin tener que abrir cada commit uno por uno
La forma que de verdad me gusta es obligar el estilo de conventional commits en los títulos de PR
Los títulos de PR pueden ser editados por el maintainer incluso después de hacer merge, no hace falta reescribir el historial de commits y, junto con herramientas como release-drafter, se puede automatizar un changelog significativo en los releases de GitHub. Eso ofrece la granularidad adecuada para las partes interesadas que menciona el autor, es decir, separar funciones, correcciones y cambios incompatibles, y también manejar automáticamente una propuesta razonable de semver para el siguiente borrador de release en GitHub
El señalamiento del artículo de que componentes como parse-lib no deberían ser opcionales es correcto, y también coincido en que obligar conventional commits puede desalentar nuevas contribuciones. Pero las alternativas tampoco son claramente mejores
Aun así, un identificador de cambio incompatible como fix!(parse-lib): Don't leave sparse holes when parsing JSON arrays transmite bastante información. Es una corrección de bug en un componente específico, con un cambio incompatible que vino de forma inevitable junto con la corrección, e implica algo como un incremento menor de semver. Ese tipo de cosas se pueden poner en el título del PR
Admito que me obsesioné demasiado con conventional commits como forma de fomentar disciplina en los commits, y al final se volvió una costumbre
Ahora a veces me parece limitante y arbitrario. En algunos proyectos ni siquiera sé si esa es la convención real, y me fui acercando más al estilo Linux/Go/Node; en un monorepo con varias configuraciones, escribir [service]: [what changed] se sentía más natural que forzar un type. De ahora en adelante quiero experimentar más con mi estilo personal de commits según lo que parezca útil, en vez de intentar encajar en una convención estricta, y los scoped commits se sienten como un buen punto de partida
chore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]
Estoy de acuerdo con casi todo, pero discrepo en una cosa sobre la parte de “mostrarles a los colaboradores un registro revisionista que reduce la confiabilidad de la historia que cuenta el log de commits”. El autor parece estar hablando sobre todo de ramas públicas, y si son ramas públicas, me parece un consejo razonable. Pero no debería aplicarse a ramas privadas. Basta con dejarlo de forma que quien revise el cambio final —el maintainer o yo dentro de 10 años— pueda entenderlo; no hace falta conservar un hilo de pensamiento incoherente o, peor aún, un montón de commits tipo address review
La respuesta a “¿por qué el scope es opcional?” es que, en proyectos pequeños, simplemente todo el proyecto es el scope
Coincido en que el “type” del commit no es tan útil, pero tampoco veo que haya una gran diferencia entre scoped commits y conventional commits. Los scoped son solo conventional sin “type”, y las distinciones entre fix, feat, refactor y chore tampoco están mal
Si todo el mundo está usando los valores predeterminados de commitlint tal cual, ¿no será más bien cuestión de hacer que la gente los use mejor?