Was macht release-notes?
Verwandelt rohe Git-Historie in Release-Notes, die ein Mensch tatsächlich lesen möchte.
Was es tut
- Differt Commits zwischen zwei Referenzen (Tags, Branches oder
HEAD) - Gruppiert Änderungen nach Typ: Features, Bugfixes, Breaking Changes, Sonstiges
- Erkennt Breaking Changes aus konventionellen Commit-
!-Markern undBREAKING CHANGE:-Fußzeilen - Entwirft einen Highlights-Abschnitt (die 3–5 Änderungen, die Nutzer wirklich interessieren)
- Gibt GitHub-Release-fertiges Markdown aus
Verwendung
# Notes für das kommende Release (letzter Tag -> HEAD)
git log $(git describe --tags --abbrev=0)..HEAD --oneline
# Zwischen zwei Tags
git log v1.2.0..v1.3.0 --pretty=format:'%h %s %b'
Dann den Agenten bitten: „Erstelle Release-Notes für v1.3.0 aus diesen Commits.“
Oder mit der GitHub CLI direkt in einen Release-Entwurf:
# Tag erstellen, dann Release-Notes aus dem Diff entwerfen
git tag v1.3.0 && git push origin v1.3.0
gh release create v1.3.0 --generate-notes --draft
# dann die generierten Notes mit diesem Skill verfeinern
Ablauf
1. Commits sammeln
git log <prev-tag>..<new-tag> --pretty=format:'%h|%s|%b|%an' --no-merges
Merge-Commits separat einschließen, falls das Repository einen merge-basierten Workflow verwendet – der Merge-Titel fasst den PR meist besser zusammen als einzelne Commits.
2. Jeden Commit klassifizieren
| Präfix / Signal | Abschnitt |
|---|---|
feat, feat! | Features |
fix | Bugfixes |
! oder BREAKING CHANGE: | ⚠️ Breaking Changes (auch in ihrem eigenen Abschnitt aufgeführt) |
perf | Performance |
docs, chore, ci, refactor, test | Zusammengefasst unter „Sonstiges“ oder ausgelassen |
Commits ohne konventionelles Präfix: Nach Nachrichteninhalt einordnen. Bei Unsicherheit lieber unter „Sonstige Änderungen“ als stillschweigend zu löschen.
3. Highlights entwerfen
Die 3–5 Änderungen auswählen, die für Nutzer der Software am wichtigsten sind:
- Neue Fähigkeiten, die sie bemerken
- Breaking Changes, auf die sie reagieren müssen
- Bugfixes für weit verbreitete Probleme
Jeden als einen einfachen Satz formulieren. Keine werblichen Adjektive.
4. Notes schreiben
## v1.3.0
**Highlights**
- ...
- ...
### ⚠️ Breaking Changes
- ...
### Features
- ...
### Bugfixes
- ...
### Sonstige Änderungen
- ...
**Vollständiges Changelog:** <prev-tag>...<new-tag>
5. Plausibilitätschecks vor der Veröffentlichung
- Jeder Breaking Change erscheint im ⚠️-Abschnitt mit einem Migrationshinweis
- Keine internen Chores werden als benutzerseitige Features dargestellt
- Beitragende werden namentlich erwähnt, wenn die Repository-Konvention das vorsieht
- Versionsnummer stimmt mit dem Tag überein
Konventionen
- Falls das Repository einen eigenen Release-Notes-Stil hat, diesen befolgen – Konsistenz geht vor jeder Vorlage.
- Falls das Repository
gh release --generate-notesverwendet, dessen Ausgabe als Grundlage nehmen und verfeinern: es bekommt die Liste richtig, aber die Highlights falsch. - Niemals Änderungen erfinden, die nicht im Commit-Bereich enthalten sind. Wenn der Bereich uneindeutig ist, nachfragen, welche Referenzen verglichen werden sollen, anstatt zu raten.