Skip to main content

Automatisch generierte Versionshinweise

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

Wer kann dieses Feature verwenden?

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. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

  2. Klicke rechts neben der Liste der Dateien auf Releases.

    Screenshot der Hauptseite eines Repositorys. Der Link mit der Bezeichnung „Releases“ ist orange umrandet.

  3. Klicke auf oben auf der Seite auf Neues Release entwerfen.

  4. Wähle im Dropdownmenü Tag auswählen ein Tag für das Release aus.

    • Um ein vorhandenes Tag zu verwenden, klicke auf das Tag.
    • Gib zum Erstellen eines neuen Tags eine Versionsnummer für dein Release ein, und klicke dann auf Neues Tag erstellen.
  5. 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.

  6. Optional kannst du über dem Beschreibungsfeld das Dropdownmenü Vorheriges Tag auswählen und dann auf das Tag klicken, das die vorherige Version kennzeichnet.

    Screenshot des Formulars „Neues Release“. Das Dropdownmenü mit der Bezeichnung „Vorheriges Tag: auto“ ist orange umrandet.

  7. Gib im Feld „Releasetitel“ einen Titel für dein Release ein.

  8. Klicken Sie oberhalb des Beschreibungsfeldes auf Versionshinweise generieren.

  9. Überprüfe die generierten Notizen, um sicherzustellen, dass sie alle (und nur) die Informationen enthalten, die du einschließen möchtest.

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

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

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

  13. Wenn GitHub Discussions für das Repository aktiviert ist, erstelle optional eine Diskussion für das Release.

    • Wähle Diskussion für dieses Release erstellen aus.
    • Wähle das Dropdownmenü Kategorie und dann eine Kategorie für die Releasediskussion aus.
  14. 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.

Konfigurieren von automatisch generierten Versionshinweisen

  1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

  2. Wähle über der Dateiliste das Dropdownmenü Add file aus, und klicke dann auf Create new file.

    Alternativ kannst du in der Dateistrukturansicht links auf klicken.

    Screenshot der Hauptseite eines Repositorys. Oberhalb der Dateiliste ist eine Schaltfläche mit der Bezeichnung „Datei hinzufügen“ dunkelorange umrandet. In der Dateistrukturansicht des Repositorys ist eine Schaltfläche mit einem Pluszeichensymbol ebenfalls dunkelorange hervorgehoben.

  3. Gib in das Feld für den Dateinamen .github/release.yml ein. Dadurch wird eine neue Datei namens release.yml im Verzeichnis .github erstellt.

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