Fügen Sie Commit-Nachrichten oder einen Unified Diff ein. Der Entwurf enthält eine Versionsstufe anhand der Commit-Markierungen; prüfen Sie diese vor der Veröffentlichung.
Läuft lokal in deinem BrowserFügen Sie Conventional-Commit-Betreffzeilen ein — gern direkt aus git log --oneline — oder einen Unified Diff, und die Seite macht daraus einen Markdown-Entwurf mit gruppierten Änderungen und einem vorgeschlagenen Level major, minor oder patch.
Hier wird kein Repository angefasst: Der eingefügte Text wird im Browser ausgewertet, die Beispiel-Schaltfläche füllt ein Muster ein, und Kopieren oder Herunterladen geben den Entwurf als release-notes.md heraus.
Commit-Betreffzeilen dürfen ein kurzes oder langes Hash-Präfix tragen, abc1234 feat: … und ein voller 40-Zeichen-Hash werden also als Commits gelesen. Ein Scope bleibt erhalten: feat(api): add filters landet unter Funktionen mit dem Scope in Klammern.
Die Typliste ist der Conventional-Commits-Satz — feat, fix, docs, style, refactor, perf, test, build, ci, chore — plus revert. Diff-Eingaben brauchen echte diff --git-Köpfe: Dateiliste und + / −-Zeilenzahlen stammen nur aus Zeilen nach einem Kopf, ein einzelnes + im Fließtext zählt also nicht als Ergänzung.
major = mindestens ein ! oder eine BREAKING-CHANGE-Fußzeile; minor = mindestens ein feat; patch = alles andere, einschließlich docs, Tests, style und chore. Das sind mechanische Regeln — lesen Sie den Entwurf, bevor Sie eine Version taggen.
Die Vorschlagszeile ist einfacher Text im Entwurf, und nichts wird irgendwo veröffentlicht: Diese Seite erzeugt nur die Ausgabe.
Sie liest kein Git-Repository, führt kein git aus und ruft keinen Netzwerkdienst auf: Ausgewertet wird nur der eingefügte Text.
Formate außerhalb dieser beiden werden gemeldet statt geraten: Ein leeres Feld antwortet mit dem Einfüge-Hinweis, und Text ohne Commit-Betreffzeile und Diff-Inhalt bekommt eine eigene Meldung. git diff --stat-Zusammenfassungen und binäre Diffs werden nicht in Zeilenstatistiken umgerechnet.