Skip to main content

Automatisch generierte Versionshinweise

Du kannst Versionshinweise für deine GitHub-Versionen automatisch generieren.

Who can use this feature

Repository collaborators and people with write access to a repository can generate and customize automated release notes for a release.

Informationen zu automatisch generierten Versionshinweisen

Automatisch 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.

Du 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.

Erstellen von automatisch generierten Versionshinweisen für ein neues Release

  1. Navigiere auf GitHub.com zur Hauptseite des Repositorys. 1. Klicke rechts neben der Liste der Dateien auf Releases. Abschnitt „Releases“ auf der rechten Randleiste
  2. Klicke auf Neues Release entwerfen. Schaltfläche für Release-Entwurf
  3. Klicke auf Tag auswählen und gib eine Versionsnummer für dein Release ein. Alternativ kannst du ein vorhandenes Tag auswählen. Eingeben eines Tags
  4. Wenn du ein neues Tag erstellst, klicke auf Neues Tag erstellen. Bestätigen, dass ein neues Tag erstellt werden soll
  5. Wenn du ein neues Tag erstellt hast, verwende das Dropdownmenü, um den Branch auszuwählen, der das zu veröffentlichende Projekt enthält. Branch auswählen
  6. Optional kannst du rechts oben im Feld mit dem Beschreibungstext das Dropdownmenü Vorheriges Tag auswählen und auf das Tag klicken, das das vorherige Release kennzeichnet. Screenshot, der zeigt, wie ein Tag ausgewählt wird, um das vorherige Release zu bestimmen
  7. Klicke rechts neben dem Beschreibungstextfeld auf Versionshinweise generieren. Versionshinweise generieren
  8. Überprüfe die generierten Notizen, um sicherzustellen, dass sie alle (und nur) die Informationen enthalten, die du einschließen möchtest.
  9. 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. Bereitstellen einer DMG mit einem Release
  10. Um Benutzer*innen darüber zu informieren, dass das Release nicht produktionsbereit und möglicherweise instabil ist, wähle Dies ist eine Vorabversion aus. Kontrollkästchen zum Markieren eines Releases als Vorabversion
  11. Wähle optional Diskussion für diesen Release erstellen aus, und wähle dann das Dropdownmenü Kategorie aus. Dann klicke auf eine Kategorie für die Releasediskussion. Kontrollkästchen zum Erstellen einer Releasediskussion und ein Dropdownmenü zum Auswählen einer Kategorie
  12. Wenn du dein Release veröffentlichen möchtest, klicke auf Release veröffentlichen. Wenn du später an dem Release arbeiten möchtest, klicke auf Entwurf speichern. Die Schaltflächen „Release veröffentlichen“ und „Entwurf speichern“

Konfigurieren von automatisch generierten Versionshinweisen

  1. Navigiere auf GitHub.com zur Hauptseite des Repositorys. 1. Klicke oberhalb der Dateiliste im Dropdownmenü Datei hinzufügen auf Neue Datei erstellen. „Neue Datei erstellen“ im Dropdownmenü „Datei hinzufügen“
  2. Gib .github/release.yml im Dateinamenfeld ein, um die Datei release.yml im Verzeichnis .github zu erstellen. Erstellen einer neuen Datei
  3. 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.

Konfigurationsoptionen

ParameterBESCHREIBUNG
changelog.exclude.labelsEine Liste von Bezeichnungen, die ausschließen, dass ein Pull Request in den Versionshinweisen angezeigt wird.
changelog.exclude.authorsEine Liste der Benutzer*innen- oder Bot-Anmeldehhandles, deren Pull Requests aus Versionshinweisen ausgeschlossen werden sollen.
changelog.categories[*].titleErforderlich. Der Titel einer Kategorie von Änderungen in Versionshinweisen.
changelog.categories[*].labelsErforderlich. Bezeichnungen, die einen Pull Request für diese Kategorie qualifizieren. Verwende * als Catch-All für Pull Requests, die keinen der vorherigen Kategorien entsprechen.
changelog.categories[*].exclude.labelsEine Liste der Bezeichnungen, die eine Pull Request ausschließen, die in dieser Kategorie angezeigt wird.
changelog.categories[*].exclude.authorsEine Liste der Benutzer*innen- oder Bot-Anmeldehhandles, deren Pull Requests aus dieser Kategorie ausgeschlossen werden sollen.

Beispielkonfigurationen

Eine Konfiguration für ein Repository, das SemVer-Releases kennzeichnet

YAML
# .github/release.yml

changelog:
  exclude:
    labels:
      - ignore-for-release
    authors:
      - octocat
  categories:
    - title: Breaking Changes 🛠
      labels:
        - Semver-Major
        - breaking-change
    - title: Exciting New Features 🎉
      labels:
        - Semver-Minor
        - enhancement
    - title: Other Changes
      labels:
        - "*"

Eine 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)

YAML
# .github/release.yml

changelog:
  categories:
    - title: 🏕 Features
      labels:
        - '*'
      exclude:
        labels:
          - dependencies
    - title: 👒 Dependencies
      labels:
        - dependencies

Weiterführende Themen