Changelog-Generator

Der Changelog-Generator wandelt Conventional-Commit-Zeilen in einen Abschnitt für CHANGELOG.md im Keep-a-Changelog-Format um und schlägt die nächste Versionsnummer vor.


Commit-Zeilen (z. B. aus git log --oneline)
Changelog-Abschnitt

    Alles läuft in Ihrem Browser. Eingaben verlassen Ihr Gerät nicht.

    Vom Commit-Log zum Changelog

    Der Changelog-Generator macht aus Commit-Zeilen im Format der Conventional Commits einen fertigen Abschnitt für Ihre CHANGELOG.md. Kopieren Sie die Ausgabe von git log --oneline v1.4.2..HEAD hinein; Commit-Hashes am Zeilenanfang werden automatisch entfernt. Aus feat wird ein Eintrag unter „Added“, aus fix unter „Fixed“, perf, refactor und revert landen unter „Changed“, und ein Scope wie (api) wird fett vorangestellt.

    Das Ausgabeformat folgt Keep a Changelog 1.1.0: neueste Version oben, Datum im Format JJJJ-MM-TT, Abschnitte in fester Reihenfolge (Added, Changed, Deprecated, Removed, Fixed, Security). Wer lieber deutsche Versionshinweise möchte, schaltet auf „Hinzugefügt, Geändert, Veraltet, Entfernt, Behoben, Sicherheit“ um. Mit einer Repository-Adresse entsteht zusätzlich der Vergleichslink zwischen beiden Versionen.

    Die neue Versionsnummer schlägt der Generator nach Semantic Versioning vor: ein Breaking Change (! oder BREAKING CHANGE:) erhöht die Hauptversion, ein neues Feature die Nebenversion, sonst steigt die Patch-Version. Ein Changelog richtet sich an Menschen: Release Notes sollten erklären, was sich für Nutzer ändert. Formulieren Sie automatisch erzeugte Einträge deshalb ruhig nach. Gute Commit-Zeilen schreiben Sie mit dem Commit-Message-Generator.

    Anleitung: Changelog-Generator in 5 Schritten

    1. Die bisherige Version eintragen und „Neue Version“ leer lassen, damit sie automatisch vorgeschlagen wird.
    2. Das Datum im Format JJJJ-MM-TT angeben und die Abschnittsnamen auf Englisch oder Deutsch wählen.
    3. Optional die Repository-Adresse für den Vergleichslink eintragen und sonstige Typen oder den Dateikopf einschalten.
    4. Die Commit-Zeilen, etwa aus git log --oneline, einfügen.
    5. Den Changelog-Abschnitt kopieren und oben in die CHANGELOG.md setzen.

    Typische Anwendungsfälle

    • Vor einem Release die Versionshinweise aus allen Commits seit dem letzten Tag erzeugen.
    • Release Notes auf GitHub oder GitLab mit einem Abschnitt im Keep-a-Changelog-Format füllen.
    • Die nächste Versionsnummer nach Semantic Versioning bestimmen, ohne die Commits einzeln durchzugehen.
    Fragen

    Häufige Fragen

    Was ist Keep a Changelog?

    Eine verbreitete Konvention für CHANGELOG.md: menschenlesbar, neueste Version oben, mit Datum und festen Abschnitten wie Added, Changed, Deprecated, Removed, Fixed und Security.

    Welche Commits werden übernommen?

    Standardmäßig feat, fix, perf, refactor, revert sowie alle Breaking Changes und Commits mit Scope security. Typen wie docs, chore, test, ci, build und style werden nur aufgenommen, wenn Sie das einschalten.

    Wie wird die Version berechnet?

    Nach Semantic Versioning: Breaking Change erhöht die erste Zahl, ein feat die zweite, alles andere die dritte. In Versionen 0.x behandeln viele Projekte Breaking Changes nur als Nebenversion; tragen Sie die Version dann von Hand ein.

    Was passiert mit Zeilen ohne Conventional-Commit-Format?

    Sie werden gezählt und unter dem Ergebnis aufgeführt. Mit „Sonstige Typen aufnehmen“ erscheinen sie unter Changed.

    Wie bekomme ich alle Commits seit dem letzten Release?

    Mit git log --oneline $(git describe --tags --abbrev=0)..HEAD in der Bash. git describe liefert den letzten Tag, der Bereich zeigt alle Commits danach.

    Was gehört unter Unreleased im Changelog?

    Keep a Changelog empfiehlt oben einen Abschnitt „Unreleased“ für Änderungen, die schon eingeflossen, aber noch nicht veröffentlicht sind. Beim Release wird er in die neue Versionsnummer mit Datum umbenannt.

    Weitere Werkzeuge

    Das könnte auch helfen

    Alle 358 Werkzeuge