CHANGELOG.md aus git log generieren
Ein CHANGELOG.md ist die Projekt-Historie aus User-Sicht: was sie in 1.2 bekamen, was in 1.3 neu ist, was in 2.0 bricht. Das Keep a Changelog-Format gruppiert Änderungen in "Features", "Bug Fixes", "BREAKING CHANGES" und ein paar mehr. Paart natürlich mit SemVer.
Das Tool liest die Ausgabe von `git log --oneline` (oder `git log --pretty=format:"%H %s"` für volle Hashes) und gruppiert Commits nach Conventional-Commit-Typ. Ergebnis: eine fertige CHANGELOG.md-Section mit Commit-Links, Datum und Versionsnummer.
Du kannst Typen ausblenden, die User nicht sehen sollten (docs, chore, ci, ...). Du kannst auch ein bestehendes CHANGELOG.md pasten, der Generator setzt die neue Section oben drauf und behält ältere Versionen. GitHub-Links werden aus der von dir angegebenen Repo-URL gebaut.
So nutzt du das Tool
- Commit-Liste im Terminal erzeugen: `git log --pretty=format:"%H %s" v1.2.0..HEAD` (Commits von Version v1.2.0 bis jetzt). Oder `git log --oneline v1.2.0..HEAD`, kurze Hashes, gleiche Daten.
- Output ins "Input"-Pane links pasten. Der Generator parst jede Zeile: Hash + Conventional Commit (Typ, Scope, Description, Breaking-Flag).
- Versions-Metadaten ausfüllen: previous (v1.2.0), current (v1.3.0), Release-Datum (per Default heute), Repo-URL (zum Bauen von `commit`-Links).
- Commit-Typen zum Einbeziehen wählen, die Chips unten im Panel. Per Default an: feat, fix, perf, revert (was User interessiert). Aus: docs, style, refactor, test, build, ci, chore (intern).
- Modus "An bestehendes CHANGELOG anhängen" (Switch), das aktuelle CHANGELOG.md pasten, der Generator setzt die neue Section über das erste `##` (also über die aktuellste Version). Der Output ist eine komplette Datei, alte überschreiben.
- Copy oder Download. In dein Repo droppen, "chore(release): v1.3.0" commiten, pushen, taggen, publishen.
Wann das nützlich ist
Konkrete Situationen, in denen ein Changelog-Generator das Release verkürzt:
- npm-/PyPI-/cargo-Release. Vor dem Publishen willst du eine "What's new in 1.3.0"-Section in der README oder in der GitHub-Release-Description. Commits seit dem letzten Tag pasten, fertige Section bekommen.
- GitHub-Release-Notes. Nach dem Tag-Push fragt GitHub "Generate release notes". Die hier generierte Section in "describe this release" pasten, sieht professionell aus und Commits sind klickbar.
- Kunden-Doku. Der Kunde will wissen, was im Sprint geliefert wurde. `git log v1.2.0..HEAD` ziehen, Changelog generieren, mailen oder in Confluence pasten. Jeder Commit verlinkt, saubere Gruppen.
- Ersatz für `semantic-release` in Projekten, wo die Automation Overkill ist. Für ein kleines Projekt, das einmal alle zwei Monate released, ist hier manuell schneller als eine volle Auto-Release-Pipeline zu konfigurieren.
- Historischer Audit. Willst du sehen, was sich exakt zwischen zwei jahrealten Versionen geändert hat? Output von `git log v0.5.0..v0.7.0` pasten, Changelog generieren, volle Zusammenfassung kriegen.
- Neue Teammitglieder onboarden. "Was ist im Projekt im letzten Jahr passiert?", ein generierter 12-Monats-Changelog gibt das ganze Bild.
Sind deine Commits noch keine Conventional Commits, nimm unseren Commit-Builder, damit neue Commits in der richtigen Form landen. Und willst du den Changelog aus einem README verlinken, hat der README-Builder eine "Changelog"-Section parat.