Aún no hay nada. Pega algunas líneas arriba y pulsa Generar.Qué hace con cada línea
Las reglas son deliberadamente simples y visibles, para que puedas predecir el resultado en lugar de adivinarlo:
- Los conventional commits se agrupan por tipo. `feat` pasa a Nuevo, `fix` a Corregido, `perf` a Mejorado. Un `!` antes de los dos puntos, o un marcador BREAKING CHANGE, mueve la línea a Cambios importantes sin importar el tipo.
- Lo que no es un conventional commit se ordena por su primera palabra. Se reconocen los VERBOS EN INGLÉS habituales en los commits: Add, Added, Introduce y Support pasan a Nuevo; Fix, Fixed y Resolve a Corregido; Improve, Update, Speed y Optimise a Mejorado; Remove, Removed, Drop y Deprecate a Eliminado. Todo lo demás cae en Otros para que lo ordenes a mano.
- Se elimina el ruido: un número de pull request al final, una línea `Merge pull request ...`, un scope entre paréntesis y el propio prefijo del tipo. La frase restante se pone en mayúscula inicial.
- Con el filtro activado se descartan las líneas con `chore`, `ci`, `test`, `build`, `style` y `refactor`, además de cualquier cosa que parezca un cambio de dependencia. Es la mayor diferencia entre un changelog que se lee y uno que se deja de leer.
Qué no puede hacer
Cambia la forma de tus mensajes de commit, no su contenido. Si un commit dice `fix: race in MembershipCache.resolve()`, eso es lo que sale, y sigue siendo una frase sobre tu código en vez de sobre la experiencia del usuario. Convertir «race in MembershipCache» en «los miembros invitados ya no ven un dashboard vacío» exige saber qué hizo el cambio, y eso es justo lo que un generador no puede inferir de una línea de asunto de commit.
Trata el resultado como un primer borrador: la estructura es correcta, la agrupación es correcta, el ruido interno ya no está, la redacción sigue siendo cosa tuya.
Preguntas frecuentes
¿Se sube algo de lo que pego?
No. El generador es un script en esta página; el texto nunca sale de tu navegador y al pulsar Generar no se hace ninguna petición hacia nosotros. Puedes comprobarlo con la pestaña de red abierta.
¿Tengo que usar conventional commits?
No. Las líneas que siguen la convención se agrupan con más precisión, y el resto recurre al verbo inicial. Un repositorio con mensajes de commit en forma de frase normal sigue produciendo un borrador utilizable.
¿Cómo obtengo esto automáticamente de mi repositorio?
Para algo puntual, `git log --pretty=format:%s v1.2.0..HEAD` te da exactamente la entrada que espera esto. Para algo continuo, git-cliff y github-changelog-generator construyen un archivo de changelog en la CI a partir de tu historial de commits, y Changeloop redacta una entrada de cara al usuario por cada pull request fusionada y la retiene para revisión.
¿Por qué mi resultado está lleno de Otros?
Los verbos iniciales no coincidían con ninguno conocido, lo que suele significar asuntos de commit que empiezan con un sustantivo o un id de ticket. Edítalos en el cuadro antes de generar, o mueve las líneas de Otros a mano después.
Para seguir leyendo: De conventional commits a un changelog, sobre lo que aporta el formato de commits y dónde se detiene.
La versión que también escribe las frases
Changeloop lee el título y la descripción de cada pull request fusionada, no solo el asunto, y redacta una entrada sobre lo que cambió para el usuario. Filtra por sí solo los cambios de dependencias y los refactors, y retiene cada borrador para que lo edites antes de publicarlo. Gratis para un repositorio, sin tarjeta.
Empezar gratis