Genera CHANGELOG.md desde git log
Un CHANGELOG.md es el historial del proyecto desde el punto de vista del usuario: qué recibió en la 1.2, qué es nuevo en la 1.3, qué se rompe en la 2.0. El formato Keep a Changelog agrupa los cambios en "Features", "Bug Fixes", "BREAKING CHANGES" y unos pocos más. Empareja naturalmente con SemVer.
Esta herramienta lee la salida de `git log --oneline` (o `git log --pretty=format:"%H %s"` para hashes completos) y agrupa los commits por tipo Conventional Commit. El resultado: una sección de CHANGELOG.md lista con enlaces de commit, una fecha y el número de versión.
Puedes ocultar tipos que no deberían ser visibles para los usuarios (docs, chore, ci, ...). También puedes pegar un CHANGELOG.md existente, el generador inserta la nueva sección arriba, manteniendo las versiones anteriores. Los enlaces a GitHub se construyen desde la URL del repo que proporciones.
Cómo usarlo
- Genera la lista de commits en la terminal: `git log --pretty=format:"%H %s" v1.2.0..HEAD` (commits desde la versión v1.2.0 hasta ahora). O `git log --oneline v1.2.0..HEAD`, hashes cortos, mismos datos.
- Pega la salida en el panel "Entrada" de la izquierda. El generador parsea cada línea: hash + Conventional Commit (tipo, scope, descripción, flag breaking).
- Rellena los metadatos de versión: anterior (v1.2.0), actual (v1.3.0), fecha de release (hoy por defecto), URL del repo (se usa para construir los enlaces `commit`).
- Elige los tipos de commit a incluir, los chips abajo del panel. Activos por defecto: feat, fix, perf, revert (los que importan a los usuarios). Desactivados: docs, style, refactor, test, build, ci, chore (internos).
- Modo "Añadir a CHANGELOG existente" (Switch): pega el CHANGELOG.md actual, el generador inserta la nueva sección encima del primer `##` (es decir, encima de la versión más reciente). La salida es un fichero completo, sobrescribe el antiguo.
- Copia o descarga el fichero. Suéltalo en tu repo, commit "chore(release): v1.3.0", push, tag, publish.
Cuándo es útil
Situaciones concretas en las que un generador de changelog acorta la release:
- Una release npm / PyPI / cargo. Antes de publicar quieres una sección "Novedades en 1.3.0" en el README o en la descripción de GitHub Release. Pega los commits desde el último tag, obtén una sección lista.
- Notas de GitHub Release. Tras hacer push de un tag, GitHub te pregunta "Generate release notes". Pega la sección generada aquí en "describe this release", se ve profesional y los commits son clicables.
- Docs cara al cliente. El cliente quiere saber qué se entregó en el sprint. Tira `git log v1.2.0..HEAD`, genera un changelog, envíalo por email o pega en Confluence. Cada commit enlazado, grupos limpios.
- Un reemplazo de `semantic-release` en proyectos donde la automatización es exagerada. Para un proyecto pequeño que hace release cada dos meses, generar manualmente aquí es más rápido que configurar un pipeline de auto-release completo.
- Una auditoría histórica. ¿Quieres ver exactamente qué cambió entre dos versiones de hace un año? Pega la salida de `git log v0.5.0..v0.7.0`, genera el changelog, obtienes un resumen completo.
- Onboarding de nuevos compañeros. "¿Qué pasó en el proyecto durante el último año?": un changelog generado de 12 meses da la foto completa.
Si tus commits no son aún Conventional Commits, usa nuestro generador de commits para que los nuevos aterricen en la forma correcta. Y si quieres enlazar el changelog desde un README, el generador de README tiene una sección "Changelog" lista.