CI/CD-Tools
Commits einfügen, aktuelle Version eintragen – und Versionsvorschlag, Changelog-Entwurf sowie Build-Nummer erhalten.
Commits und Versionsnummer werden im Browser geparst. Nichts wird hochgeladen, und es wird kein Git- oder CI-Dienst aufgerufen.
Commits einfügen oder eine Version eingeben, um zu beginnen.
Nicht erkannte Zeilen blockieren die Berechnung nie; diese Option entscheidet nur, ob sie im Abschnitt „Other“ des Changelog-Entwurfs erscheinen.
Commits einfügen oder eine Version eingeben, um zu beginnen.
Vor einem Release beantwortet man meist drei Fragen von Hand: Wie lautet die nächste Versionsnummer, was gehört in den Changelog, und welche Build-Nummer bekommt dieses Release? Dieses Tool lässt aus denselben Commits einen Changelog aus Commits generieren und liefert gleichzeitig Versionsvorschlag und Build-Nummer, sodass alle drei nie auseinanderlaufen.
Der Unterschied zu einer manuell hochgezählten Version oder von Hand eingetragenen CHANGELOG.md-Zeilen: Jeder Vorschlag stammt aus dem Parsen der Commit-Header nach derselben Grammatik wie unser Conventional Commit Builder – nicht aus geratenen Diffs oder einem KI-Aufruf. Nichts, was Sie einfügen, verlässt den Browser, und das Tool erstellt niemals einen Tag, pusht nichts und ruft keine Git- oder CI-API auf – es erzeugt nur Text zur eigenen Verwendung.
So verändert es sich, wenn Version, Changelog und Build-Nummer aus denselben Commits stammen.
Manche Semantic-Release-Rechner lassen Sie Änderungen als Freitext beschreiben und schicken ihn an eine KI, die eine Versionsänderung rät. Dieses Tool parst stattdessen jede Commit-Header-Zeile nach derselben Conventional-Commit-Grammatik wie unser Conventional Commit Builder – dieselbe Eingabe ergibt immer denselben Vorschlag, und es wird nie eine Netzwerkanfrage gesendet.
Ein eigenständiger Versionsrechner, ein Changelog-Generator und ein Build-Nummer-Generator kennen die Ausgabe des jeweils anderen nicht. Hier fließt die vorgeschlagene Version direkt in die Changelog-Überschrift und in den Platzhalter {version} Ihrer Build-Nummer-Vorlage, sodass alle drei synchron bleiben. Der erzeugte Changelog eignet sich auch, um daraus Release Notes generieren zu können.
Sobald das Release erstellt ist, verlinkt das Ergebnisfeld direkt zu unserem ENV-Diff-Tool, damit Sie Umgebungsvariablen vor dem Deployment vergleichen können – ein Schritt, den die von uns verglichenen eigenständigen Changelog- und Build-Nummer-Generatoren nicht bieten.
Was Sie wissen sollten, bevor Sie Ihren ersten Stapel Commits einfügen.
Fügen Sie die Zeilen so ein, wie `git log --pretty=format:%s` sie ausgibt – eine `type(scope)!: subject`-Zeile pro Commit. Mehrzeilige Commit-Nachrichten mit Body oder `BREAKING CHANGE:`-Footer werden hier nicht geparst; markieren Sie Breaking Changes stattdessen mit `!` direkt nach Typ oder Scope.
Geben Sie die aktuelle Version als strikte SemVer-Zeichenkette ein (z. B. 1.4.2) und passen Sie bei Bedarf die Build-Nummer-Vorlage an. Die Standardvorlage `{version}+{yyyyMMdd}.{count}` nutzt die vorgeschlagene Version, das heutige Datum und einen selbst eingegebenen Build-Zähler – das Tool hat keinen CI-Kontext, aus dem es eine echte Build-Nummer lesen könnte.
Automatische Generierung ausschalten, um mehrere Felder zu bearbeiten, bevor Sie die nächste Version mit Ctrl/Cmd+Enter einmal manuell berechnen.
Das Badge (Major, Minor, Patch oder keine Änderung) zeigt, welcher Commit die Änderung ausgelöst hat – ein Breaking-Marker gewinnt immer gegenüber einem einfachen feat oder fix. Kopieren oder laden Sie den Changelog herunter, kopieren Sie die Build-Nummer, oder folgen Sie dem ENV-Diff-Link, bevor Sie taggen.
Jede Eingabeänderung graut das vorherige Ergebnis aus und deaktiviert Kopieren/Herunterladen, bis Sie neu generieren.
Sehen, was nicht geparst wirdVier Bausteine, die aus Commit-Headern einen einsatzbereiten Release-Entwurf machen.
Dieses Tool liest `type(scope)!: subject`-Zeilen nach derselben Grammatik wie unser Conventional Commit Builder, bewertet die Auswirkung jeder erkannten Zeile und behält die höchste – ein einziges `!` oder ein `feat` irgendwo im Stapel reicht, um das ganze Release anzuheben.
Erkannte Commits werden in Breaking Changes, Features, Fixes und Other gruppiert und als Markdown gerendert, das Sie kopieren oder als CHANGELOG.md herunterladen können – Breaking-Einträge stehen immer ganz oben.
Kombinieren Sie `{version}`, `{yyyy}`, `{yyyyMM}`, `{yyyyMMdd}` und einen manuell eingegebenen `{count}` zu jedem Build-Nummer-Format, das Ihre Pipeline erwartet; unbekannte Platzhalter bleiben unverändert stehen und werden markiert statt still verworfen.
Eine Zeile, die kein gültiger Commit-Header ist, wird für den Versionsvorschlag übersprungen und separat gezählt, statt die gesamte Berechnung zu stoppen – schalten Sie „Ignorieren“ aus, um sie trotzdem unter Other im Changelog zu sehen.
Randfälle, die Sie kennen sollten, bevor Sie Commits eines echten Releases einfügen.
Antworten auf das, was Leute wirklich fragen, bevor sie einem commit-basierten Versionsvorschlag vertrauen.
Prüfen Sie, ob die Zeile exakt dem Muster `type(scope)!: subject` entspricht – ein fehlender Doppelpunkt, ein überzähliges Leerzeichen oder nicht unterstützte Syntax macht die ganze Zeile unerkennbar, und nicht erkannte Zeilen fließen nie in den Versionsvorschlag ein. Die Anzahl erkannter Zeilen unter dem Ergebnis zeigt, wie viele Zeilen tatsächlich geparst wurden.
Bearbeiten Sie die Build-Nummer-Vorlage in den Optionen. Die Standardvorlage `{version}+{yyyyMMdd}.{count}` fügt die von diesem Tool vorgeschlagene Version, das heutige Datum und einen selbst eingegebenen Zähler ein – hier gibt es keine CI-Umgebung, aus der eine echte Build-Nummer gelesen werden könnte, daher bleibt `{count}` manuell.
Die Versionsnummer (wie 1.5.0) folgt Semantic Versioning und wird durch die Auswirkung Ihrer Commits bestimmt. Die Build-Nummer ist eine eigene, aus einer Vorlage erzeugte Zeichenkette – nützlich für CI-Systeme, die auch bei gleicher Versionsnummer jeden Build eindeutig unterscheiden müssen. Sie kann über `{version}` dieselbe Version enthalten, dazu aber ein Datum und einen manuell eingegebenen `{count}`.
Fügen Sie Commits einfach als einen Header pro Zeile ein – dieses Tool lässt daraus einen Changelog aus Commits generieren, gruppiert nach feat, fix und Breaking Changes, im Keep-a-Changelog-Stil. Kopieren Sie ihn oder laden Sie ihn als CHANGELOG.md herunter, statt ihn von Hand abzuschreiben.
Eine Zeile, die nicht dem Muster `type(scope)!: subject` entspricht, wird als „nicht erkannt“ gezählt und fließt nicht in die Berechnung des Versionsvorschlags ein. Standardmäßig ist „Nicht erkannte Zeilen ignorieren“ aktiv, sodass sie auch nicht im Changelog-Entwurf erscheint – schalten Sie diese Option aus, wenn Sie sie trotzdem sehen möchten.
Antwort nicht gefunden?
Fügen Sie Ihre Commits ein, bestätigen Sie die aktuelle Version und erhalten Sie in Sekunden einen Versionsvorschlag, einen Changelog-Entwurf und eine Build-Nummer.
Alles läuft lokal in Ihrem Browser – keine Anmeldung, kein Upload, und es wird nie für Sie getaggt oder deployt.
Das gesamte Parsing findet lokal in Ihrem Browser statt und es wird nie für Sie getaggt oder veröffentlicht.