Changelog: Was ist das? Mit Beispiel-Eintrag
5 Min. Lesezeit
Ein Changelog ist das datierte Protokoll dessen, was sich in einem Produkt geändert hat, geschrieben für die Menschen, die die Änderung betrifft, nicht für das Team, das sie ausgeliefert hat. Jeder Eintrag benennt eine Änderung, sagt, wann sie wirksam wurde, und sagt, was die Leserin damit tun soll, was bei den meisten Einträgen: nichts. Genau das unterscheidet ein Changelog von einem Commit-Log: Ein Commit-Log ist ein Protokoll für die Menschen, die den Code geschrieben haben, ein Changelog ist ein Protokoll für die Menschen, die ihn benutzen.
Was ist ein Changelog, genau genommen?
Eine Liste datierter Einträge, neueste zuerst, jeder beschreibt eine einzelne Änderung so, dass die Leserin danach handeln kann. Nicht was das Team gebaut hat, sondern was jetzt anders ist. „Billing-Service refactored” ist eine Commit-Message. „Rechnungen zeigen Steuern jetzt als eigene Zeile” ist ein Changelog-Eintrag, weil er der Leserin etwas sagt, das sie am eigenen Konto nachprüfen kann.
Das Format ist alt und bewusst schlicht: eine Überschrift pro Release oder pro Tag, eine kurze Liste darunter, manchmal eine Kategorie-Markierung. Keep a Changelog ist die meistzitierte Spezifikation für diese Form, und sie existiert, weil die meisten Projekte ohne Spezifikation stattdessen ihre Commit-Historie abkippen, was eine andere Frage beantwortet als die, mit der die Leserin gekommen ist.
| Dokument | Geschrieben für | Beantwortet |
|---|---|---|
| Changelog | Alle, die das Produkt benutzen | Was hat sich geändert, und wann? |
| Commit-Log | Das Team, das den Code geschrieben hat | Was wurde getan, in welcher Reihenfolge? |
| Release Notes | Nutzerinnen, die entscheiden, ob sie updaten | Was kann ich jetzt, was vorher nicht ging? |
| Patch Notes | Spielerinnen oder Nutzerinnen eines konkreten Fixes | Was hat genau dieses Release behoben? |
| Roadmap | Alle, die wissen wollen, was als Nächstes kommt | Was ist geplant, und wie weit ist es? |
Die fünf überschneiden sich in der Praxis, sind aber nicht dasselbe Dokument, und der Unterschied liegt darin, wer sie in der Hand hält, wenn sie gelesen werden. Ein Changelog ist das Dokument, das gebaut ist, um durchsucht und später wieder verlinkt zu werden, weshalb Einträge mehr als die anderen feste Daten und stabile URLs brauchen.
Was enthält ein Changelog-Eintrag eigentlich?
Vier Dinge, in dieser Reihenfolge: Was sich geändert hat, formuliert so, wie die Nutzerin oder der aufrufende Client es bemerken würde; wann es wirksam wurde; welcher Kategorie es angehört (Added, Fixed, Changed, Removed sind die vier gängigen); und, wenn es zählt, was die Leserin deswegen tun muss. Ein Link zu mehr Detail ist willkommen. Ein Absatz interner Rechtfertigung nicht, denn die Leserin hat nicht nach dem Warum gefragt, sondern nach dem Was.
## 2026-09-07
### Added
- Rechnungen zeigen Steuern jetzt als eigene Zeile, in der Kontowährung
des Kunden.
### Fixed
- Beim CSV-Export eines Reports fehlte die letzte Zeile, sobald der
Report mehr als 10.000 Zeilen umfasste.Diese Form skaliert von einer Zwei-Zeilen-Änderung bis zu hundert Einträgen in einem Release, ohne die Struktur zu wechseln, und das ist der eigentliche Test dafür, ob ein Format funktioniert: Liest es sich in einer vollen Woche noch genauso wie in einer ruhigen.
Wer schreibt ein Changelog, und wann?
Wer die Änderung gemacht hat, im Moment des Ausliefern, nicht eine technische Redakteurin, die es eine Woche später aus Tickets rekonstruiert. Wer den Code angefasst hat, weiß, was sich für die Nutzerin tatsächlich geändert hat; eine nachträglich geschriebene Zusammenfassung neigt dazu, das Ticket zu beschreiben statt das, was wirklich ausgeliefert wurde, und das ist meist breiter oder enger als der tatsächliche Umfang. Manche Teams bauen einen Review-Schritt ein, bevor ein Eintrag öffentlich wird, hauptsächlich um interne Sprache abzufangen, die sich eingeschlichen hat, und dieser Review sollte schnell genug sein, dass der Eintrag noch am selben Tag veröffentlicht wird.
Wo lebt ein Changelog?
Auf einer eigenen Seite, unter einer stabilen URL, als Feed syndiziert. Vergraben in einem Einstellungsmenü oder einem Release-Tag auf einem Code-Host erreicht es nur Leute, die schon wussten, wo sie nachschauen müssen. Eine öffentliche Seite lässt sich aus einem Support-Ticket verlinken, in einer Review zitieren oder abonnieren. Der Feed zählt genauso viel wie die Seite: Eine Leserin, die einmal im Monat auf das Changelog eines Produkts schaut, ist selten, eine, die ihn abonniert, nicht, und nur der Feed bedient die zweite Gruppe.
Wie unterscheidet sich ein Changelog von Release Notes?
Die beiden werden ständig verwechselt und sind unterschiedlich genug, dass eine Vermischung ein Dokument ergibt, das keiner der beiden Leserinnen wirklich dient. Changelog vs Release Notes geht die Unterscheidung vollständig durch; kurz gesagt ist ein Changelog das vollständige, chronologische Protokoll, und Release Notes sind eine kuratierte Auswahl, geschrieben, damit ein Update lesenswert klingt. Ein Produkt braucht meist beides, gerichtet an unterschiedliche Momente im Tag der Leserin.
Was macht ein Changelog lesenswert?
Konkretheit und Ehrlichkeit über den eigenen Umfang. „Diverse Bugfixes” ist der Satz, der einer Leserin beibringt, die Seite nicht mehr zu öffnen, weil er nichts verspricht, das sie nachprüfen kann. Ein Eintrag, der genau das benannte Verhalten nennt, das sich geändert hat, selbst bei einem kleinen Fix, ist der, der ein Abonnement am Leben hält. Diese Disziplin gilt auch fürs Weglassen: Ein Changelog, das nur je Erfolge verkündet und nie einen Fix für etwas Kaputtes, liest sich wie Marketing im Changelog-Gewand, und Leserinnen merken das.
Auch Versionierungsdisziplin gehört dazu. Semantic Versioning und dein Changelog zeigt, wie Versionsnummer und Eintrag zusammenpassen sollten, damit eine Leserin, die die Versionshistorie überfliegt, dasselbe Signal zweimal bekommt statt zwei unterschiedliche.
Wie entstehen Changelogs?
Auf zwei Wegen, und die meisten realen Setups sind eine Mischung. Automatisierte Generierung liest Commit-Messages, meist im Conventional-Commits-Format, und macht daraus Einträge, ohne dass jemand die Ausgabe anfasst; Von Conventional Commits zum Changelog beschreibt diese Pipeline. Kuratierte Generierung heißt, jemand schreibt oder überarbeitet jeden Eintrag von Hand. Automatisierte Ausgabe ist schneller und verpasst nie einen gemergten Pull Request, übernimmt aber jede vage Commit-Message wortwörtlich, weshalb die meisten Teams, die automatisieren, trotzdem einen leichten Redigierschritt vor der Veröffentlichung behalten, statt die Rohausgabe direkt zu zeigen.
FAQ
Braucht jedes Produkt ein Changelog? Jedes Produkt mit Nutzerinnen, die von Änderungen betroffen sind, braucht eines, ob SaaS-App, internes Tool oder öffentliche API. Die Form passt sich an (ein API-Changelog liest sich anders als das einer Consumer-App), der Bedarf nicht.
Was ist ein Changelog in der Softwareentwicklung? Dieselbe Definition wie oben: eine datierte, chronologische Liste dessen, was sich in der Software geändert hat, geschrieben für die Menschen, die sie benutzen, nicht für die, die sie gebaut haben.
Kann ein Changelog automatisch aus Commits generiert werden? Ja, viele Teams tun genau das, meist aus Conventional-Commits-Messages. Der Nachteil: Ein generierter Eintrag ist nur so klar wie die Commit-Message, aus der er stammt, weshalb ein Review-Durchgang vor der Veröffentlichung die unklaren Fälle abfängt.
Ist ein Changelog dasselbe wie eine Versionshistorie? Nah genug, dass die Begriffe oft austauschbar benutzt werden. Eine Versionshistorie ist manchmal nur eine Liste aus Versionsnummern und Daten ohne Beschreibung; ein Changelog enthält immer, was sich geändert hat.
Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.