Changelog-Beispiele 2026: 8 starke Beispiele + Vorlage

Ein Changelog ist eine fortlaufende Liste der wichtigen Änderungen in jeder Version eines Produkts, die neueste zuerst. Ein gutes Changelog-Beispiel gruppiert Einträge nach Typ (Added, Changed, Fixed, Removed), zeigt bei jedem Release eine Versionsnummer und ein Datum und ist für Menschen geschrieben, nicht für Maschinen. Der Rest ist Stilfrage.

Schwierig wird es erst, wenn du sehen willst, wie das aussieht, wenn ein echtes Team es Woche für Woche pflegt. Unten findest du acht echte Changelogs, jeweils mit Screenshot, mit dem, was sie richtig machen, und mit einer Gewohnheit, die du übernehmen kannst. Danach bekommst du eine Vorlage zum Kopieren, die Formatregeln und eine kurze Anleitung zur Automatisierung.

Wenn du wegen der Ankündigungsseite eines Releases hier bist, hilft dir der Beitrag dazu, wie du Release Notes schreibst. Ein Changelog ist das Protokoll. Release Notes sind die Geschichte, die du über ein einzelnes Release erzählst. Du brauchst beides, und beides speist sich gegenseitig.

Die 8 Changelog-Beispiele auf einen Blick

Jeder Changelog unten löst ein anderes Problem. Eine Bibliothek braucht Diff-Links, eine API braucht laute Hinweise auf Breaking Changes, und eine Desktop-App braucht Versionsnummern, die Nutzer mit ihrem Build abgleichen können.

Such dir das Beispiel aus, das deiner Zielgruppe am nächsten ist, und übernimm Ideen aus den anderen.

8 Changelog-Beispiele, die sich zum Nachmachen lohnen

1. Die eigene CHANGELOG.md von Keep a Changelog

Ideal für: Open-Source-Projekte, die dem Referenzformat aufs Wort folgen wollen.

Keep a Changelog ist die Spezifikation, die die meisten Entwickler meinen, wenn sie „Changelog-Format“ sagen. Das Projekt pflegt seine eigene CHANGELOG.md auf GitHub, und das ist das sauberste Changelog-Beispiel, das du finden wirst. Die Datei beginnt mit einer Überschrift # Changelog und einer zweizeiligen Einleitung. Diese Einleitung nennt das Format, dem die Datei folgt, und sagt, dass das Projekt Semantic Versioning nutzt.

Direkt darunter steht ein Abschnitt Unreleased. Er sammelt Änderungen, die gemergt, aber noch nicht ausgeliefert sind. Beim Release benennen die Maintainer ihn in die neue Version um und legen einen frischen an.

Was er richtig macht:

• Eine Überschriftenform für jedes Release. Jede Version lautet ## [2.0.0] - 2026-06-07. Das Datum folgt ISO 8601, also musst du nicht raten, ob 06/07 Juni oder Juli bedeutet.
• Nur die Gruppen, die er braucht. Version 2.0.0 nutzt Removed, Changed und Added. Leere Gruppen fallen weg, statt als leere Überschriften stehen zu bleiben.
• Breaking Changes direkt im Eintrag markiert. Einträge, die etwas kaputt machen, beginnen mit einem fetten Breaking:-Präfix. Sie bleiben in ihrer normalen Gruppe, statt in einen eigenen Abschnitt zu wandern.
• Diff-Links am Ende. Die Versionsnummern in eckigen Klammern sind Markdown-Referenzlinks. Jeder zeigt auf eine GitHub-Vergleichsansicht zwischen zwei Tags, sodass Leser den genauen Code-Diff sehen.

Übernimm das: den kurzen Einleitungsabsatz über einem großen Release. Version 2.0.0 beginnt mit ein paar Sätzen dazu, was bricht und was gültig bleibt. Danach übernehmen die Listen.

Pass auf bei: Eine einfache Datei hat keine Suche, keine Filter und keinen Abo-Button. Für eine Bibliothek ist das in Ordnung. Für ein Produkt mit nicht-technischen Nutzern willst du zusätzlich eine Webseite.

2. Die CHANGELOG.md von React

Ideal für: große Bibliotheken mit vielen Paketen und vielen Mitwirkenden.

Der React Changelog ist eine einzige Markdown-Datei mit mehr als 3.000 Zeilen. Jedes Release bekommt eine Überschrift mit Version und ausgeschriebenem Datum, etwa 19.3.0 (September 9, 2026).

Große Releases teilen sich dann in Abschnitte wie „New React Features“, „New React DOM Features“ und „All Changes“. Unter „All Changes“ sind die Einträge nach Paket gruppiert: React, React DOM, React Server Components und so weiter.

Was er richtig macht:

• Gruppierung nach Paket. Wer nur React DOM nutzt, springt direkt zu diesem Abschnitt. In einem Monorepo ist das oft nützlicher als eine Gruppierung nur nach Änderungstyp.
• Jeder Eintrag ist nachvollziehbar. Die meisten Punkte enden mit dem GitHub-Handle des Autors und Links zu den Pull Requests dahinter. Der ViewTransition-Eintrag in 19.3.0 verlinkt Dutzende PRs.
• Kurze, direkte Einträge. Zeilen wie „Fix useDeferredValue getting stuck“ sagen in wenigen Wörtern, was sich geändert hat.

Übernimm das: Nenne Mitwirkende beim Namen. Das kostet eine Zeile und belohnt die Leute, die die Arbeit gemacht haben.

Pass auf bei: Die Datumsformate schwanken innerhalb der Datei („Jan 26, 2026“, „October 1st, 2025“). Genau deshalb empfiehlt die Spezifikation YYYY-MM-DD.

3. Stripe API Changelog

Ideal für: APIs, bei denen ein einziger Breaking Change den Checkout eines Kunden lahmlegen kann.

Der Stripe Changelog liegt mitten in der Entwicklerdoku. Sein Untertitel ist schlicht: Änderungen und Upgrades der Stripe API im Blick behalten. Releases sind unter Namen wie Dahlia, Clover, Basil und Acacia gruppiert. Darin tragen API-Versionen ein Datum plus den Release-Namen, etwa 2026-08-26.dahlia.

Jede Änderung steht in einer Tabellenzeile. Die Zeile zeigt einen Titel, die betroffenen Produkte, ob die Änderung ein Breaking Change ist, und eine Kategorie. Jeder Titel verlinkt auf eine eigene Seite mit den Details.

Was er richtig macht:

• Ein Filter für „Breaking changes“. Oben auf der Seite gibt es eine Suche plus Filter für Breaking Changes, Produkt und Kategorie. Ein Integrator kann alles ausblenden außer dem, was seinen Code kaputt machen könnte.
• Versionen, die zugleich Daten sind. 2026-08-26.dahlia verrät dir in einem String, wann die Version erschienen ist und zu welchem Major-Release sie gehört.
• Tabs für allgemein verfügbar und Public Preview. Preview-Änderungen haben einen eigenen Tab, damit sie die stabile Liste nicht zumüllen.

Übernimm das: ein Ja-oder-Nein-Feld „Breaking“ an jedem Eintrag. Wenn eine Änderung Geld kosten kann, sollen Leser nie erst den Fließtext lesen müssen, um das herauszufinden.

Pass auf bei: Diese Tiefe ist für API-Integratoren gebaut. Eine Consumer-App braucht sie nicht.

4. GitHub Changelog

Ideal für: Plattformen mit vielen Produkten und einem großen, gemischten Publikum.

Der GitHub Changelog gehört zum GitHub-Blog. Die Einträge sind nach Monat gruppiert. Jeder ist eine kurze Karte mit Datum, Typ-Label, verlinktem Titel und Produkt-Tags wie Copilot oder Actions.

Es gibt drei Typ-Labels: Release, Improvement und Retired. Über ein Filter-Panel grenzt du die Liste nach Produktbereich ein, und im Kopf findest du eine RSS-Feed-URL und einen Link, um dem Changelog-Account auf X zu folgen.

Was er richtig macht:

• Ein Label „Retired“. Abkündigungen und Abschaltungen bekommen ein eigenes Label und eine eigene Farbe, damit man sie kaum übersieht. „SHA-1 in HTTPS on GitHub sunset“ ist dort einsortiert.
• Ein Beitrag pro Änderung. Jeder Eintrag hat eine eigene URL. So teilst du eine einzelne Änderung leicht im Team-Chat oder in einer Support-Antwort.
• Mehrere Wege, dranzubleiben. RSS, ein Social-Account und eine Newsletter-Anmeldung sorgen dafür, dass Leute Updates dort bekommen, wo sie ohnehin lesen.

Übernimm das: Gib Entfernungen ein eigenes, sichtbares Label. Die meisten Changelog-Leser suchen nur nach einer Sache: „Verschwindet etwas, das ich nutze?“

Pass auf bei: Es gibt keine Versionsnummern, weil GitHub.com ständig ausliefert. Für einen gehosteten Dienst funktioniert das. Für Software, die Leute installieren, würde es nicht funktionieren.

5. Linear Changelog

Ideal für: SaaS-Produkte, bei denen der Changelog auch Marketing ist.

Der Linear Changelog steht in einem Bereich „Now“ neben Produktlaunches und Team-Beiträgen. Jeder Eintrag ist ein datierter Beitrag, etwa „Loops for product management“ vom 14. September 2026. Versionsnummern gibt es nicht.

Ein Beitrag beginnt mit dem Hauptfeature: ein Titel, ein Produktvideo oder ein großer Screenshot und ein paar Absätze zum Problem, das es löst. Darunter folgen gruppierte Listen kleiner Änderungen unter Überschriften wie Fixes, Improvements und API. Jeder Punkt trägt ein kurzes Bereichs-Label.

Was er richtig macht:

• Zwei Ebenen in einem Beitrag. Gelegenheitsleser bekommen die Geschichte und das Video. Power-User scrollen nach unten zur vollständigen Liste der Fixes.
• Erst das Problem, dann das Feature. Der Text erklärt, warum Teams die Änderung brauchen, bevor er erklärt, was der Button macht.
• Links zur Doku. Beiträge verweisen für Einrichtungsdetails auf die Doku, damit der Changelog kurz bleibt.

Übernimm das: die Listen mit Fixes und Improvements unter der Hauptgeschichte. Kleine Fixes beweisen, dass sich jemand um ein Produkt kümmert. Wer sie versteckt, verschenkt diesen Beweis.

Pass auf bei: Ohne Versionen kann ein Nutzer, der einen Bug meldet, nicht sagen, welchen Build er hatte. Für eine Web-App, die alle gleichzeitig bekommen, ist das in Ordnung.

6. Supabase Changelog

Ideal für: Entwicklerplattformen, die oft Breaking Changes und Abkündigungen ausliefern.

Der Supabase Changelog besteht aus einem Beitrag pro Änderung, der neueste zuerst. Jeder Beitrag zeigt Titel, Datum, ein Typ-Label und einen oder mehrere Produktbereiche, dann eine kurze Zusammenfassung.

Die Typ-Labels lohnen sich, Wort für Wort übernommen zu werden: New Feature, Improvement, Bug Fix, Breaking Change, Deprecation und Policy. Die Bereichs-Labels decken Dinge wie Auth, Database, Storage, Realtime und die Client-Bibliotheken ab.

Was er richtig macht:

• Breaking Change und Deprecation sind vollwertige Labels. Leser erkennen sie, ohne einen Beitrag zu öffnen.
• Fristen in klaren Worten. Viele Beiträge sagen, was du tun musst und bis wann, etwa ein Upgrade auf eine neuere Version vor einem festen Datum.
• RSS und „Copy as Markdown“. Im Kopf gibt es einen RSS-Button und einen Button, der den Changelog als Markdown kopiert. Das ist praktisch, um ihn in interne Notizen einzufügen.

Übernimm das: ein Label „Policy“. Änderungen an Preisen, Limits und Bedingungen sind auch Änderungen, und Nutzer hassen es, sie zufällig zu entdecken.

Pass auf bei: Titel tragen manchmal Stufen-Tags in unterschiedlichen Stilen („[Public Alpha]“, „Feature Preview:“, „(Beta)“). Entscheide dich für ein Muster und bleib dabei.

7. Raycast Changelog

Ideal für: Desktop- und Mobile-Apps, bei denen Nutzer sehen, welche Version sie verwenden.

Der Raycast Changelog hat Tabs für jede Plattform: macOS, Windows, iOS und das ältere macOS V1. Jeder Eintrag zeigt eine Versionsnummer und ein Datum, etwa v2.4 vom 14. September 2026. Die Version verlinkt auf eine eigene Seite.

Ein Eintrag beginnt mit einem Titelbild und einer kurzen Einleitung. Danach kommen drei feste Abschnitte: New, Improvements und Fixes, jeweils mit einem Emoji. Jeder Punkt beginnt mit einem fetten Bereichs-Label wie „AI Chat:“ oder „Clipboard History:“.

Was er richtig macht:

• Eigene Tabs pro Plattform. Mac-Nutzer müssen nichts über Windows-Fixes lesen, und umgekehrt.
• Bereichs-Labels an jedem Punkt. Du suchst nach dem Feature, das du nutzt, und überspringst den Rest.
• Ehrliche Einleitungen. Große Releases erklären Kompromisse in klarer Sprache, nicht nur die guten Nachrichten.

Übernimm das: die feste Reihenfolge New / Improvements / Fixes. Wenn jedes Release dieselben drei Blöcke nutzt, lernen Leser, wo sie nachschauen müssen.

Pass auf bei: Der Versionssprung von v0.71 auf v2.0 ergibt erst mit dem Beitrag zu 2.0 einen Sinn. Wenn du neu nummerierst, sag das im Changelog selbst.

8. ScreenSnap Pro Changelog (Schritt für Schritt erklärt)

Ideal für: kleine Teams, die oft ausliefern und für Nicht-Entwickler schreiben.

Das letzte Beispiel ist der ScreenSnap Pro Changelog, eine App für Screenshots und Bildschirmaufnahmen auf Mac und Windows. Er eignet sich gut zum Durchgehen, weil er die Entscheidungen zeigt, die ein kleines Team trifft, gute wie schlechte. So zerfällt ein Eintrag, anhand der Nummern im Screenshot:

1. Version und Badge. v5.8.2 in großer Schrift, daneben ein Badge „Release“.
2. Datum. „September 13, 2026“, ausgeschrieben und rechtsbündig.
3. Zusammenfassung. Unter einer Überschrift „What's New“ gibt ein Satz das Thema vor: Dieses Update macht die Capture History unter Windows und macOS zuverlässiger.
4. Die Änderungsliste. Sechs Punkte in klarem Englisch. Jeder beschreibt, was der Nutzer bemerkt, nicht, was der Code tut.
5. Abschluss. Ein kurzes „Thank you for using ScreenSnap Pro!“ zum Schluss.

Was er richtig macht:

• Die Zusammenfassung in einem Satz. Leser wissen in fünf Sekunden, ob das Release für sie wichtig ist.
• Nutzersprache. „Captures taken with Capture and Edit or OCR now appear in History“ ist ein Fix, der über seine Wirkung beschrieben wird.
• Plattform genannt, wenn es zählt. Fixes, die nur Windows betreffen, sagen das auch.

Was besser sein könnte:

• Keine Typ-Gruppen. Fixes und Verbesserungen teilen sich eine Liste. Überschriften wie Added, Changed und Fixed würden bei längeren Releases helfen.
• Das Badge bringt wenig. Jeder aktuelle Eintrag heißt „Release“, also sagt das Label Lesern nichts Neues.
• Keine Links pro Version und kein Feed. Du kannst weder auf eine einzelne Version verlinken noch per RSS abonnieren.
• Lücken in der Nummerierung. Einige Patch-Versionen fehlen (die Seite springt von v5.7.1 auf v5.7.3). Die Spezifikation rät, dass jede Version einen Eintrag bekommt, selbst wenn er nur eine Zeile lang ist.

Übernimm das: die Zusammenfassung. Von allen Gewohnheiten auf dieser Seite ist sie am günstigsten einzuführen.

Was die besten Changelog-Beispiele gemeinsam haben

1. Neueste zuerst. Jedes Beispiel stellt die jüngste Änderung nach oben.
2. Ein Datum an jedem Eintrag. Versionen sind optional. Daten nicht.
3. Einheitliche Gruppen. Keep a Changelog nutzt Added, Changed und Fixed. Raycast nutzt New, Improvements und Fixes. Supabase nutzt Labels. Die Namen unterscheiden sich, aber jedes Team verwendet jedes Mal dieselben.
4. Breaking Changes sind laut. Ein fettes Präfix, ein Filter, ein farbiges Label. Niemand versteckt sie im Fließtext.
5. Für den Leser geschrieben. Keiner kopiert ein rohes Commit-Log hinein.
6. Verlinkbar. Fast alle geben jeder Version oder jedem Beitrag eine eigene URL oder einen Anker.
7. Ein Weg zum Dranbleiben. RSS, E-Mail, Social Media oder ein Feed im Produkt. Ein Changelog, den niemand sieht, erfüllt seinen Zweck nicht.

Wenn dein Changelog diese sieben Dinge tut, ist er schon besser als die meisten.

Changelog-Format: Keep a Changelog vs Common Changelog

Zwei schriftliche Spezifikationen decken die meisten Changelog-Formate im Open-Source-Bereich ab. Sie sind sich in vielem einig, trennen sich aber bei ein paar Details.

Common Changelog ist eine strengere Auslegung von Keep a Changelog. Es ist für Pakete gebaut, die Git-Tags und Semantic Versioning nutzen.

Welche solltest du wählen? Keep a Changelog ist die sicherere Standardwahl, und seine sechs Typen decken Sicherheitsfixes und Abkündigungen ab. Common Changelog passt zu Paket-Maintainern, die jede Zeile bis zu einem Commit und einem Autor zurückverfolgen wollen.

Für eine SaaS- oder Desktop-App übernimmst du die Teile, die deinen Lesern helfen: Daten, Gruppen, Marker für Breaking Changes und Links.

Changelog vs Release Notes: Was ist der Unterschied?

Viele verwechseln die beiden ständig, und manche Teams nennen beides einfach Release-Log. Hier die einfache Version.

Keep a Changelog 2.0.0 bringt es gut auf den Punkt: Der Changelog ist die Quelle, und Release Notes werden daraus abgeleitet. Beim Release ist der Abschnitt der Version in deinem Changelog schon der erste Entwurf der Release Notes. Kopier ihn und ergänze Screenshots und ein paar Zeilen Kontext.

Für die Ankündigungsseite hat die Release-Notes-Vorlage Versionen zum Kopieren für große Releases, Patches und „Neu“-Karten in der App.

Eine Changelog-Vorlage zum Kopieren

Diese Vorlage folgt Keep a Changelog 2.0.0. Füge sie als CHANGELOG.md im Root deines Repos ein und ersetze die Beispielzeilen. Die Typnamen (Added, Changed, Fixed usw.) bleiben auf Englisch, weil die Spezifikation genau diese Wörter vorgibt.

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- Export history as CSV from the Settings page.

## [2.1.0] - 2026-09-18

Faster search and a new export option. No breaking changes.

### Added

- Saved searches you can pin to the sidebar.
- CSV export for the activity log.

### Changed

- Search results now load in under a second on large projects.

### Deprecated

- The `legacy_sort` option. It will be removed in 3.0.0. Use `sort_by` instead.

### Fixed

- Dates in exported PDFs now use your time zone.
- The app no longer freezes when you paste a long file name.

## [2.0.0] - 2026-08-02

### Changed

- **Breaking:** `parse()` now returns a result object instead of throwing.
  See the upgrade guide for the two-line fix.

### Removed

- **Breaking:** Support for Node 16.

### Security

- CVE-2026-00000: Fix path traversal in the file upload handler.

## [1.4.2] - 2026-07-15 [YANKED]

### Fixed

- Crash on startup for some Windows users.

[Unreleased]: https://github.com/you/project/compare/v2.1.0...HEAD
[2.1.0]: https://github.com/you/project/compare/v2.0.0...v2.1.0
[2.0.0]: https://github.com/you/project/compare/v1.4.2...v2.0.0
[1.4.2]: https://github.com/you/project/releases/tag/v1.4.2

Die CVE-Nummer oben ist ein Platzhalter. Setz deine eigene ein und verlinke auf das vollständige Advisory.

Eine Web-Changelog-Vorlage für Apps

Wenn dein Changelog auf einer Webseite steht und deine Leser keine Entwickler sind, funktioniert eine leichtere Form besser. Das ist das Muster, das Raycast und ScreenSnap Pro teilen, ergänzt um Typ-Gruppen:

## v3.2.0 · September 18, 2026

One sentence on what this release is about.

**New**
- **Area:** What the user can now do.

**Improved**
- **Area:** What got faster, easier or clearer.

**Fixed**
- **Area:** What was broken and now works.

Halte die Reihenfolge in jedem Release gleich. Lass jede Gruppe weg, die leer ist.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 39 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

Formatregeln, die deine Release-Historie lesbar halten

Das sind die Regeln, die am meisten zählen, abgeleitet aus beiden Spezifikationen und den acht Beispielen oben.

Gruppiere Änderungen nach Typ

Wähl eine kleine Menge an Änderungstypen und bleib dabei. Die sechs von Keep a Changelog (Added, Changed, Deprecated, Removed, Fixed, Security) sind der Standard.

Die Spezifikation hat auch eine Entscheidungshilfe für die häufigste Frage. War das alte Verhalten ein Bug, gehört der Eintrag unter Fixed. Hat es wie gedacht funktioniert und funktioniert jetzt anders, gehört er unter Changed. Widersteh neuen Kategorien wie „Performance“ oder „Dependencies“. Ein schnellerer Parser ist ein Changed-Eintrag. Ein Dependency-Update gehört nur in den Changelog, wenn Nutzer seine Wirkung spüren.

Nutze ISO-Daten

Schreib Daten als YYYY-MM-DD. Das Format sortiert korrekt, liest sich in jedem Land gleich und ist ein ISO-Standard. Auf einer Webseite kannst du ein freundlicheres Datum anzeigen. Behalte das ISO-Datum in der Datei oder im Seiten-Markup.

Sag, welches Versionsschema du nutzt

Semantic Versioning ist die gängige Wahl: MAJOR für Breaking Changes, MINOR für neue Features, PATCH für Fixes. Es ist nicht die einzige. Calendar Versioning passt gut zu Apps, die nach Zeitplan ausliefern, und die datierten API-Versionen von Stripe sind eine Variante davon.

Produkte, die ständig deployen, können Versionen weglassen und datierte Einträge führen, so wie GitHub, Linear und Supabase.

Markiere Breaking Changes direkt am Eintrag

Setz ein Breaking:-Präfix an die Zeile und lass sie in ihrer normalen Gruppe. Sag, was bricht: die API, die Kommandozeile, ein Dateiformat oder eine Konfigurationsoption.

Füg einen einzeiligen Fix hinzu, wenn er passt. Braucht der Fix mehr als ein paar Schritte, verlinke auf einen Migrationsleitfaden, statt alles in den Changelog zu schreiben.

Kündige ab, bevor du entfernst

Markiere ein Feature in einem Release als Deprecated. Entferne es in einem späteren und nenne die Version, die es entfernen wird. So haben Nutzer Zeit zum Planen. Wenn du sonst nichts festhältst, halte Abkündigungen, Entfernungen und Breaking Changes fest.

Mach jede Version verlinkbar

Auf eine Versionsüberschrift sollte man verlinken können. In einer Markdown-Datei heißt das Referenzlinks auf Vergleichsansichten, wie in der Vorlage. Auf einer Webseite heißt das ein Anker oder eine Seite pro Version.

„Behoben in 2.1.0“ mit Link schließt Support-Tickets schneller als „In einem der letzten Updates behoben“.

Lass zurückgezogene Releases sichtbar

Wenn du ein Release wegen eines ernsten Bugs zurückziehst, lösch seinen Eintrag nicht. Markiere es mit [YANKED], damit Leute, die es installiert haben, wissen, warum es verschwunden ist.

Schreib für Leser, nicht für Reviewer

Jeder Eintrag sollte für sich allein verständlich sein. „Login gefixt“ ist eine Notiz an dich selbst. „Fehler behoben, durch den du in Safari nach 5 Minuten abgemeldet wurdest“ ist ein Changelog-Eintrag.

Vorher und nachher: schwache Changelog-Einträge umschreiben

Die meisten schwachen Changelogs sind aus Entwicklersicht geschrieben. Hier sind vier typische Einträge, umgeschrieben für den Leser.

Das Muster: Fang mit dem an, was der Nutzer bemerkt, nenne den Bereich, ergänze den Fix, wenn etwas gebrochen ist, und streich alles, was niemand vermissen würde.

Wenn dein Team Bugs in einem klaren Format mit „erwartet vs. tatsächlich“ meldet, ist die halbe Arbeit schon erledigt. Eine gute Bug-Report-Vorlage beschreibt das Problem bereits aus Nutzersicht, sodass sich der Fixed-Eintrag fast von selbst schreibt.

So automatisierst du deinen Changelog, ohne den menschlichen Teil zu verlieren

Automatisierung kann Stunden sparen, aber jede Spezifikation und jedes Beispiel oben ist sich in einem Punkt einig. Ein rohes Commit-Log ist kein Changelog. Tools können Entwürfe liefern, Menschen sollten entscheiden, was wichtig ist.

Strukturierte Commits

Conventional Commits gibt Commit-Nachrichten eine feste Form, etwa feat: oder fix:. Tools lesen diese Präfixe, um die nächste Versionsnummer zu bestimmen und einen Changelog zu entwerfen.

• release-please öffnet einen Release-Pull-Request mit einem Changelog-Entwurf, den du vor dem Mergen bearbeiten kannst.
• semantic-release läuft in der CI und veröffentlicht Version und Notes für dich.
• Changesets bittet Mitwirkende, zu jedem Pull Request eine kurze Änderungsnotiz zu schreiben. So steckt der menschliche Satz von Anfang an drin.
• git-cliff baut einen Changelog aus deiner Git-Historie mit einer Vorlage, die du selbst steuerst.

Vom Host generierte Release Notes

GitHub kann Release Notes automatisch generieren, und zwar aus gemergten Pull Requests. Das ist ein schneller Start. Keep a Changelog 2.0.0 warnt, dass diese Notes in der Datenbank des Hosts liegen, nicht in deinem Repo, und deshalb nicht mit deinem Code umziehen. Nutze sie als Entwurf und behalte CHANGELOG.md als Protokoll.

KI-Entwürfe

Ein Sprachmodell kann aus einem Diff in Sekunden einen flüssigen Changelog machen. Genau das ist auch das Risiko: Es ist jetzt leicht, einen Changelog zu veröffentlichen, den niemand gelesen hat. Wenn du eines nutzt, gib ihm dasselbe Briefing, das du einem neuen Mitwirkenden geben würdest:

1. Fasse nur wichtige Änderungen zusammen, die Nutzer betreffen.
2. Füge nie das Git-Log ein.
3. Sortiere jede Änderung in einen der sechs Typen ein.
4. Markiere Breaking Changes.
5. Streich alles, was sich nicht zu lesen lohnt.

Leg dieses Briefing in einer Datei AGENTS.md oder CLAUDE.md ab, damit Coding-Agents es jedes Mal sehen. Lies den Entwurf dann, bevor du ihn veröffentlichst.

Lass die CI nur unterstützen

Lass die CI den Abschnitt Unreleased in eine datierte Version verschieben und das Format prüfen. Mach eine Changelog-Änderung nicht zur Pflichtprüfung für jeden Pull Request, sonst fügen Leute Zeilen nur hinzu, um die Prüfung zu bestehen.

Screenshots und GIFs in deinen Changelog-Einträgen

Schau dir die acht Beispiele noch einmal an. Die Web-Changelogs, die lebendig wirken (Linear, Raycast, Supabase), nutzen Bilder oder Videos für ihre großen Features. Ein Changelog ist überwiegend Text, aber ein Visual erklärt ein neues Feature schneller als drei Absätze.

Ein paar Regeln halten Visuals nützlich:

• Zeig die Änderung, nicht den ganzen Bildschirm. Schneide auf das Panel oder den Button zu, der sich geändert hat.
• Nutze ein GIF oder ein kurzes Video für alles, was sich bewegt. Eine 5-Sekunden-Schleife zeigt einen neuen Drag-and-drop-Ablauf besser als ein Standbild.
• Annotiere sparsam. Ein Pfeil oder nummerierte Markierungen, wie beim ScreenSnap Pro Beispiel oben. Nicht zehn.
• Halte Dateien klein. Ein GIF mit 20 MB bremst die ganze Seite. Du kannst ein GIF im Browser komprimieren, mit Qualitätsregler und Frame-Skipping, bevor du es einbettest, oder dieser Anleitung folgen, um die GIF-Dateigröße zu verringern.

Mehr zu Größe, Zuschnitt und Benennung von Bildern in Dokus findest du in dieser Anleitung zu Screenshots in technischer Dokumentation. Wenn du einen Recorder suchst, vergleicht diese Übersicht über Tools für GIF-Bildschirmaufnahmen die Optionen.

Genau hier lohnt sich eine eigene Aufnahme-App. ScreenSnap Pro nimmt einen Bereich, ein Fenster oder den ganzen Bildschirm auf, zeichnet GIFs und Videos auf und hat 15 Annotationswerkzeuge, darunter Pfeile, einen nummerierten Zähler und Weichzeichner, um Kundendaten zu verbergen. Der Cloud-Upload gibt dir einen Link, den du in deinen Changelog oder Release-Beitrag einfügst. Die App läuft auf Mac und Windows und kostet einmalig 39 $, ohne Abo.

Häufig gestellte Fragen

Was ist ein gutes Changelog-Beispiel?

Die CHANGELOG.md im Repository von Keep a Changelog ist die klarste Referenz. Sie zeigt den Abschnitt Unreleased, ISO-Daten, gruppierte Änderungstypen, Breaking:-Marker und Vergleichslinks. Für eine Webseite sind Raycast und Supabase gute Vorbilder für Apps und Entwicklerplattformen.

Was sollte ein Changelog enthalten?

Jedes Release braucht eine Versionsnummer (oder ein Datum, wenn du nicht versionierst), ein Release-Datum und die wichtigen Änderungen, nach Typ gruppiert. Die Standardtypen sind Added, Changed, Deprecated, Removed, Fixed und Security. Breaking Changes sollten am Eintrag markiert sein, und jede Version sollte verlinkbar sein.

Was ist der Unterschied zwischen einem Changelog und Release Notes?

Ein Changelog ist das vollständige, fortlaufende Protokoll jeder wichtigen Änderung über alle Versionen hinweg. Release Notes kündigen ein einzelnes Release an, wählen die Highlights aus und ergänzen oft Kontext, Screenshots oder Upgrade-Schritte. Schreib zuerst den Changelog und leite die Release Notes daraus ab.

Was ist das Format von Keep a Changelog?

Keep a Changelog ist eine weit verbreitete Spezifikation für CHANGELOG.md-Dateien. Sie listet die neueste Version zuerst, nutzt Daten im Format YYYY-MM-DD, gruppiert Änderungen in sechs Typen, hält oben einen Abschnitt Unreleased und markiert zurückgezogene Versionen mit [YANKED]. Version 2.0.0 erschien im Juni 2026 und behält dasselbe Dateiformat bei.

Kann ich einen Changelog aus Git-Commits generieren?

Einen Entwurf, ja. Tools wie release-please, semantic-release und git-cliff lesen strukturierte Commit-Nachrichten und bauen daraus einen Changelog. Behandle das Ergebnis als Rohmaterial. Ein Mensch muss trotzdem Rauschen streichen, zusammengehörige Commits bündeln und Einträge für den Leser umschreiben.

Fang mit einer Gewohnheit an

Du musst deinen Changelog nicht diese Woche komplett neu aufbauen. Such dir eine Gewohnheit aus den Beispielen oben aus: eine Zusammenfassung in einem Satz, ein Breaking:-Präfix, eine Gruppe Fixed oder ISO-Daten. Bau sie in dein nächstes Release ein.

Mach den nächsten Eintrag dann mit einem klaren Screenshot leichter lesbar. Wenn du Bilder schneller aufnehmen, annotieren und teilen willst, ist ScreenSnap Pro ein einmaliger Kauf für 39 $. Eine Lizenz für 2 Computer, Mac oder Windows. Zu den Preisen.