Noch nichts da. Fügen Sie oben ein paar Zeilen ein und klicken Sie auf Generieren.Was mit jeder Zeile passiert
Die Regeln sind bewusst einfach und sichtbar, damit Sie die Ausgabe vorhersagen können, statt sie zu erraten:
- Conventional Commits werden nach Typ gruppiert. `feat` wird zu Neu, `fix` zu Behoben, `perf` zu Verbessert. Ein `!` vor dem Doppelpunkt oder ein BREAKING-CHANGE-Marker verschiebt die Zeile unabhängig vom Typ zu Breaking Changes.
- Alles, was kein Conventional Commit ist, wird nach seinem ersten Wort sortiert. Erkannt werden dabei die ENGLISCHEN Verben, wie sie in Commit-Nachrichten üblich sind: Add, Added, Introduce und Support werden zu Neu; Fix, Fixed und Resolve zu Behoben; Improve, Update, Speed und Optimise zu Verbessert; Remove, Removed, Drop und Deprecate zu Entfernt. Alles andere landet in Sonstiges, das Sie von Hand einsortieren.
- Rauschen wird entfernt: eine angehängte Pull-Request-Nummer, eine `Merge pull request ...`-Zeile, ein Scope in Klammern und das Typ-Präfix selbst. Der verbleibende Satz wird großgeschrieben.
- Mit aktivem Filter fallen Zeilen mit `chore`, `ci`, `test`, `build`, `style` und `refactor` heraus, ebenso alles, was nach einem Dependency-Bump aussieht. Das ist der größte einzelne Unterschied zwischen einem Changelog, das gelesen wird, und einem, bei dem man aufhört.
Was er nicht kann
Er verändert die Form Ihrer Commit-Nachrichten, nicht deren Inhalt. Steht in einem Commit `fix: race in MembershipCache.resolve()`, dann kommt genau das heraus, und es ist weiterhin ein Satz über Ihren Code statt über das Erleben der Nutzenden. Aus „race in MembershipCache“ ein „eingeladene Mitglieder sehen kein leeres Dashboard mehr“ zu machen setzt Wissen darüber voraus, was die Änderung bewirkt hat, und genau das kann ein Generator aus einer Commit-Betreffzeile nicht ableiten.
Behandeln Sie die Ausgabe also als ersten Durchgang: Struktur stimmt, Gruppierung stimmt, internes Rauschen ist weg, die Formulierung bleibt Ihre Aufgabe.
Häufige Fragen
Wird etwas hochgeladen, das ich einfüge?
Nein. Der Generator ist ein Skript auf dieser Seite; der Text verlässt Ihren Browser nicht, und beim Klick auf Generieren geht keine Anfrage an uns. Sie können das mit offenem Netzwerk-Tab überprüfen.
Muss ich Conventional Commits verwenden?
Nein. Zeilen, die der Konvention folgen, werden genauer gruppiert, alles andere fällt auf das einleitende Verb zurück. Ein Repository mit gewöhnlichen Commit-Nachrichten in Satzform liefert weiterhin einen brauchbaren Entwurf.
Wie bekomme ich das automatisch aus meinem Repository?
Für einen einmaligen Lauf liefert `git log --pretty=format:%s v1.2.0..HEAD` genau die Eingabe, die hier erwartet wird. Für den laufenden Betrieb erzeugen git-cliff und github-changelog-generator in der CI eine Changelog-Datei aus Ihrer Commit-Historie, und Changeloop entwirft pro gemergtem Pull Request einen Eintrag für Nutzende und hält ihn zur Durchsicht bereit.
Warum steht in meiner Ausgabe überall Sonstiges?
Die einleitenden Verben passten zu keinem bekannten Muster, was meist an Commit-Betreffzeilen liegt, die mit einem Substantiv oder einer Ticket-ID beginnen. Bearbeiten Sie sie entweder im Feld, bevor Sie generieren, oder verschieben Sie die Zeilen unter Sonstiges danach von Hand.
Weiterlesen: Von Conventional Commits zum Changelog, dazu, was das Commit-Format bringt und wo es aufhört.
Die Variante, die auch die Sätze schreibt
Changeloop liest Titel und Beschreibung jedes gemergten Pull Requests, nicht nur die Betreffzeile, und entwirft daraus einen Eintrag darüber, was sich für die Nutzenden geändert hat. Dependency-Bumps und Refactorings sortiert es von selbst aus und hält jeden Entwurf zur Bearbeitung bereit, bevor er veröffentlicht wird. Kostenlos für ein Repository, ohne Karte.
Kostenlos starten