Entwicklung
Changelog aus den Commits erzeugen
Vor jeder Veröffentlichung dieselbe Frage: Was ist eigentlich drin? Die Commit-Liste beantwortet das nicht, weil sie für Entwickler geschrieben ist und nicht für die Leute, die das Produkt benutzen.
- Aufbau
- 2 Stunden
- Spart
- Von einer Stunde auf zehn Minuten pro Veröffentlichung
- Womit
- Claude · GitHub · n8n
So läuft es ab
- 1
Zeitraum abgrenzen
Alles zwischen der letzten Veröffentlichung und jetzt.
- 2
Sortieren
Neue Funktionen, Verbesserungen, Fehlerbehebungen — interne Umbauten fallen raus.
- 3
Übersetzen
Aus »refactor auth middleware« wird »Anmeldung ist zuverlässiger geworden«. Aus Nutzersicht, nicht aus Codesicht.
- 4
Entwurf ablegen
Als Entwurf für die Veröffentlichung. Vor dem Erscheinen liest jemand drüber.
Wo es nicht funktioniert
Was in der Commit-Nachricht nicht steht, kann auch der Changelog nicht wissen. Wenn die Nachrichten aus »wip« und »fix« bestehen, ist das erste Problem nicht der Changelog.
Fertig gebaut kaufen
Wenn du den Aufbau überspringen willst — aus der Kategorie Coding.
Häufige Fragen
Brauche ich dafür ein festes Commit-Format?
Es hilft sehr, ist aber keine Bedingung. Ein Format wie Conventional Commits macht die Einordnung eindeutig; ohne es muss das Sprachmodell mehr raten, kommt aber bei brauchbaren Nachrichten trotzdem weit.
Sollen interne Änderungen erscheinen?
Im Changelog für Nutzer nicht. Sinnvoll sind zwei Fassungen: eine für Nutzer, eine vollständige für das Team.
Kann das automatisch veröffentlicht werden?
Technisch ja. Es lohnt sich trotzdem, kurz drüberzulesen — der Changelog ist oft das Einzige, was Nutzer von deiner Arbeit lesen.