{"meta":{"title":"Automatisch generierte Versionshinweise","intro":"Sie können Veröffentlichungsnotizen für Ihre GitHub-Versionen automatisch generieren.","product":"Repositories","breadcrumbs":[{"href":"/de/repositories","title":"Repositories"},{"href":"/de/repositories/releasing-projects-on-github","title":"Veröffentlichen von Projekten"},{"href":"/de/repositories/releasing-projects-on-github/automatically-generated-release-notes","title":"Automatisierte Versionshinweise"}],"documentType":"article"},"body":"# Automatisch generierte Versionshinweise\n\nSie können Veröffentlichungsnotizen für Ihre GitHub-Versionen automatisch generieren.\n\n## Informationen zu automatisch generierten Versionshinweisen\n\nAutomatisch generierte Versionshinweise bieten eine automatisierte Alternative zum manuellen Schreiben von Versionshinweisen für deine GitHub-Releases. Mit automatisch generierten Versionshinweisen kannst du schnell einen Überblick über den Inhalt einer Version erstellen. Automatisch generierte Versionshinweise umfassen eine Liste der zusammengeführten Pull Requests, eine Liste der Mitwirkenden an der Version und einen Link zu einem vollständigen Änderungsprotokoll.\n\nDu kannst auch deine automatisierten Versionshinweise anpassen, indem du Beschriftungen verwendest, um benutzerdefinierte Kategorien zu erstellen, um Pull Requests zu strukturieren, die du einschließen möchtest, und um bestimmte Bezeichnungen und Benutzer\\*innen aus der Ausgabe auszuschließen.\n\n## Erstellen von automatisch generierten Versionshinweisen für ein neues Release\n\n1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.\n2. Klicke rechts neben der Liste der Dateien auf **Releases**.\n\n   ![Screenshot der Hauptseite eines Repositorys. Der Link mit der Bezeichnung „Releases“ ist orange umrandet.](/assets/images/help/releases/release-link.png)\n3. Klicke auf oben auf der Seite auf **Neues Release entwerfen**.\n4. Wähle im Dropdownmenü **Tag auswählen** ein Tag für das Release aus.\n   * Um ein vorhandenes Tag zu verwenden, klicke auf das Tag.\n   * Gib zum Erstellen eines neuen Tags eine Versionsnummer für dein Release ein, und klicke dann auf **Neues Tag erstellen**.\n5. Wenn du ein neues Tag erstellt hast, verwende das Dropdownmenü **Ziel**, und klicke dann auf den Branch, der das zu veröffentlichende Projekt enthält.\n6. Optional kannst du über dem Beschreibungsfeld das Dropdownmenü **Vorheriges Tag** auswählen und dann auf das Tag klicken, das die vorherige Version kennzeichnet.\n\n   ![Screenshot des Formulars „Neues Release“. Das Dropdownmenü mit der Bezeichnung „Vorheriges Tag: auto“ ist orange umrandet.](/assets/images/help/releases/releases-tag-previous-release.png)\n7. Gib im Feld „Releasetitel“ einen Titel für dein Release ein.\n8. Klicken Sie oberhalb des Beschreibungsfeldes auf **Versionshinweise generieren**.\n9. Überprüfe die generierten Notizen, um sicherzustellen, dass sie alle (und nur) die Informationen enthalten, die du einschließen möchtest.\n10. Um optional binäre Dateien wie kompilierte Programme in deinen Release einzubinden, ziehe die Dateien mit Drag-and-Drop herüber oder wähle die Dateien manuell im Feld für Binärdateien.\n11. Um Benutzer\\*innen darüber zu informieren, dass das Release nicht produktionsbereit und möglicherweise instabil ist, wähle optional **Dies ist eine Vorabversion** aus.\n12. Wähle optional **Als neueste Version festlegen** aus. Wenn du diese Option nicht auswählst, wird die neueste Versionsbezeichnung automatisch auf Basis der semantischen Versionierung zugewiesen.\n13. Wenn GitHub Discussions für das Repository aktiviert ist, erstelle optional eine Diskussion für das Release.\n    * Wähle **Diskussion für dieses Release erstellen** aus.\n    * Wähle das Dropdownmenü **Kategorie** und dann eine Kategorie für die Releasediskussion aus.\n14. Wenn du dein Release veröffentlichen möchtest, klicke auf **Release veröffentlichen**. Wenn Sie später an der Version arbeiten möchten, klicken Sie auf **\"Entwurf speichern**\".  Wenn Sie unveränderliche Versionen für das Repository aktiviert haben, können Sie beim Erstellen eines Entwurfs zuerst alle Objekte anfügen, bevor die Version unveränderlich wird.\n    Du kannst dann deine veröffentlichten oder Entwurf-Releases im Release-Feed deines Repositorys ansehen. Weitere Informationen finden Sie unter [Releases und Tags Ihres Repositories anzeigen](/de/repositories/releasing-projects-on-github/viewing-your-repositorys-releases-and-tags).\n\n## Konfigurieren von automatisch generierten Versionshinweisen\n\n1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.\n2. Wähle über der Liste der Dateien das Dropdownmenü **Add file** <svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon octicon-triangle-down\" aria-label=\"The downwards-facing triangle icon\" role=\"img\"><path d=\"m4.427 7.427 3.396 3.396a.25.25 0 0 0 .354 0l3.396-3.396A.25.25 0 0 0 11.396 7H4.604a.25.25 0 0 0-.177.427Z\"></path></svg> aus, und klicke auf **<svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon octicon-plus\" aria-label=\"plus\" role=\"img\"><path d=\"M7.75 2a.75.75 0 0 1 .75.75V7h4.25a.75.75 0 0 1 0 1.5H8.5v4.25a.75.75 0 0 1-1.5 0V8.5H2.75a.75.75 0 0 1 0-1.5H7V2.75A.75.75 0 0 1 7.75 2Z\"></path></svg> Create new file**.\n\n   Alternativ kannst du in der Dateistrukturansicht links auf <svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon octicon-plus\" aria-label=\"The plus sign icon\" role=\"img\"><path d=\"M7.75 2a.75.75 0 0 1 .75.75V7h4.25a.75.75 0 0 1 0 1.5H8.5v4.25a.75.75 0 0 1-1.5 0V8.5H2.75a.75.75 0 0 1 0-1.5H7V2.75A.75.75 0 0 1 7.75 2Z\"></path></svg> klicken.\n\n   ![Screenshot der Hauptseite eines Repositorys, auf dem das Symbol „Add file“ und das Pluszeichen, die beide oben beschrieben wurden, orange umrandet sind.](/assets/images/help/repository/add-file-buttons.png)\n3. Gib in das Feld für den Dateinamen `.github/release.yml` ein. Dadurch wird eine neue Datei namens `release.yml` im Verzeichnis `.github` erstellt.\n4. Gib in der Datei mithilfe der nachstehenden Konfigurationsoptionen in YAML die Pull-Request-Bezeichnungen und Autoren an, die du aus diesem Release ausschließen möchtest. Du kannst auch neue Kategorien erstellen und die Pull-Request-Bezeichnungen auflisten, die in jede dieser Kategorien einbezogen werden sollen.\n\n### Konfigurationsoptionen\n\n| Parameter                                                                                                                                                                                  | BESCHREIBUNG                                                                                                                |\n| :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- |\n| `changelog.exclude.labels`                                                                                                                                                                 | Eine Liste von Bezeichnungen, die ausschließen, dass ein Pull Request in den Versionshinweisen angezeigt wird.              |\n| `changelog.exclude.authors`                                                                                                                                                                | Eine Liste der Nutzer- oder Bot-Anmeldehandles, deren Pull Requests aus den Versionshinweisen ausgeschlossen werden sollen. |\n| `changelog.categories[*].title`                                                                                                                                                            |                                                                                                                             |\n| **Erforderlich.** Der Titel einer Kategorie von Änderungen in Versionshinweisen.                                                                                                           |                                                                                                                             |\n| `changelog.categories[*].labels`                                                                                                                                                           |                                                                                                                             |\n| **Erforderlich.** Bezeichnungen, die einen Pull Request für diese Kategorie qualifizieren. Verwende `*` als Catch-All für Pull Requests, die keinen der vorherigen Kategorien entsprechen. |                                                                                                                             |\n| `changelog.categories[*].exclude.labels`                                                                                                                                                   | Eine Liste von Labels, die eine Pull Request davon ausschließen, in dieser Kategorie angezeigt zu werden.                   |\n| `changelog.categories[*].exclude.authors`                                                                                                                                                  | Eine Liste der Nutzer- oder Bot-Anmeldehandles, deren Pull Requests aus dieser Kategorie ausgeschlossen werden sollen.      |\n\n### Beispielkonfigurationen\n\nEine Konfiguration für ein Repository, das SemVer-Releases kennzeichnet\n\n```yaml copy\n# .github/release.yml\n\nchangelog:\n  exclude:\n    labels:\n      - ignore-for-release\n    authors:\n      - octocat\n  categories:\n    - title: Breaking Changes 🛠\n      labels:\n        - Semver-Major\n        - breaking-change\n    - title: Exciting New Features 🎉\n      labels:\n        - Semver-Minor\n        - enhancement\n    - title: Other Changes\n      labels:\n        - \"*\"\n```\n\nEine Konfiguration für ein Repository, das keine Pull Requests taggt, aber in der automatisierte Dependabot-Pull Requests in Versionshinweisen getrennt werden sollen (`labels: '*'` ist erforderlich, um eine Catchall-Kategorie anzuzeigen)\n\n```yaml copy\n# .github/release.yml\n\nchangelog:\n  categories:\n    - title: 🏕 Features\n      labels:\n        - '*'\n      exclude:\n        labels:\n          - dependencies\n    - title: 👒 Dependencies\n      labels:\n        - dependencies\n```\n\n## Weiterführende Lektüre\n\n* [Verwalten von Labels](/de/issues/using-labels-and-milestones-to-track-work/managing-labels)"}