Skip to main content

Verfügbare Regeln für Regelsätze

Hier erfährst du, welche Regeln du einem Regelsatz hinzufügen kannst, um bestimmte Branches und Tags in einem Repository zu schützen.

Wer kann dieses Feature verwenden?

Alle Personen mit Lesezugriff auf ein Repository können die Regelsätze des Repositorys anzeigen. Personen mit Administratorzugriff auf ein Repository oder mit einer benutzerdefinierten Rolle mit der Berechtigung „Repositoryregeln bearbeiten“, können Regelsätze für ein Repository erstellen, bearbeiten und löschen sowie Erkenntnisse zu Regelsätzen anzeigen. Weitere Informationen findest du unter Informationen zu benutzerdefinierten Repositoryrollen.

Regelsätze sind verfügbar in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen, und in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team und GitHub Enterprise Cloud. Weitere Informationen findest du unter GitHub-Pläne.

Du kannst Regelsätze erstellen, um zu steuern, wie Benutzer*innen mit ausgewählten Branches und Tags in einem Repository interagieren können. Wenn du einen Regelsatz erstellst, kannst du die in den folgenden Abschnitten beschriebenen Regeln aktivieren oder deaktivieren.

Wenn du einen Regelsatz erstellst, kannst du bestimmten Benutzerinnen erlauben, die Regeln darin zu umgehen. Das können Benutzerinnen mit bestimmten Berechtigungen, bestimmte Teams oder GitHub Apps sein. Weitere Informationen findest du unter „Informationen zu Regelsätzen“.

Weitere Informationen zum Erstellen von Regelsätzen findest du unter "Erstellen von Regelsätzen für Repositorys in deiner Organisation" und "Erstellen von Regelsätzen für ein Repository".

Einschränken von Erstellungen

Wenn diese Option ausgewählt ist, können nur Benutzer mit Umgehungsberechtigungen Branches oder Tags erstellen, deren Name dem von dir angegebenen Muster entspricht.

Einschränken von Updates

Wenn diese Option ausgewählt ist, können nur Benutzer*innen mit Umgehungsberechtigungen an Branches oder Tags pushen, deren Name dem von dir angegebenen Muster entspricht.

Einschränken von Löschungen

Wenn diese Option ausgewählt ist, können nur Benutzer mit Umgehungsberechtigungen Branches oder Tags löschen, deren Name dem von dir angegebenen Muster entspricht. Diese Regel ist standardmäßig ausgewählt.

Erfordern eines linearen Verlaufs

Durch das Erzwingen eines linearen Commitverlaufs wird verhindert, dass Projektmitarbeiter*innen Mergecommits an die anvisierten Branches oder Tags pushen. Das bedeutet, dass alle Pull Requests, die in den Branch oder das Tag gemergt sind, einen Squashmerge oder einen Rebasemerge verwenden müssen. Ein streng linearer Commitverlauf kann Teams dabei helfen, Änderungen einfacher rückgängig zu machen. Weitere Informationen zu Mergemethoden findest du unter Informationen zum Zusammenführen von Pull Requests.

Bevor du einen linearen Commit-Verlauf verlangen kannst, muss dein Repository Squash-Merge oder Rebase-Merge erlauben. Weitere Informationen findest du unter Pull-Request-Merges konfigurieren.

Erfordern von Mergewarteschlangen

Note

  • Das Konfigurieren einer Mergewarteschlange über Regelsätze befindet sich in der öffentlichen Betaphase und kann geändert werden.
  • Diese Regel ist nicht für Regelsätze verfügbar, die auf Organisationsebene erstellt wurden. Weitere Informationen zum Erstellen von Regelsätzen auf Repository-Ebene finden Sie unter „Erstellen von Regelsätzen für ein Repository.“

Sie können festlegen, dass Zusammenführungen mit einer Mergewarteschlange auf Repository-Ebene ausgeführt werden müssen. Weitere Informationen zu Mergewarteschlangen findest du unter Zusammenführen eines Pull Requests mit einer Mergewarteschlange.

Zusätzliche Einstellungen

Sie können verschiedene Einstellungen für ihre Regel für die Mergewarteschlange konfigurieren.

  • Merge-Methode: Methode, die beim Zusammenführen von Änderungen aus Pull Requests verwendet werden soll.
  • Buildparallelität: Beschränkung der Anzahl der in die Warteschlange eingereihten Pull Requests, die Überprüfungen bei gleichzeitiger Ausführung von Workflows anfordern.
    • Diese Einstellung steuert, wann die Mergewarteschlange den Ereigniswebhook merge_group.checks_requested versendet, der GitHub Actions-Workflows auslöst, die für die Ausführung auf merge_group konfiguriert sind. Weitere Informationen findest du unter Webhook-Ereignisse und -Nutzlasten.
    • Wenn beispielsweise 5 Pull Requests zur Warteschlange hinzugefügt wurden und die Einstellung für die Buildparallelität 3 ist, sendet die Warteschlange Ereignis checks_requested für die ersten 3 Pull Requests. Sobald sie ein Ergebnis für einen dieser Pull Requests empfängt, sendet die Mergewarteschlange das Ereignis für den 4. Pull Request usw.
  • Minimale/maximale Gruppengröße: Die Anzahl der Pull Requests, die in einer Gruppe zusammengeführt werden.
  • Wartezeit zum Erreichen der minimalen Gruppengröße (Minuten): Wartezeit der Mergewarteschlange nach Hinzufügen des ersten Pull Request , damit die minimale Gruppengröße erreicht wird. Nach Ablauf dieser Zeit wird die minimale Gruppengröße ignoriert und eine kleinere Gruppe zusammengeführt.
  • Alle Warteschlangeneinträge müssen vorhanden sein, um erforderliche Prüfungen zu durchlaufen:
    • Wenn diese Einstellung aktiviert ist, muss jedes Element in der Mergegruppe alle erforderlichen Prüfungen bestehen.
    • Wenn diese Einstellung deaktiviert ist, muss zur Zusammenführung nur das Commit an der Kopfzeile der Mergegruppe, d. h. das Commit, das Änderungen aus allen Pull Requests in der Gruppe enthält, die erforderlichen Überprüfungen bestehen.
  • Statusüberprüfungstimeout (Minuten): Maximale Zeit bis zur Abschlussmeldung für den erforderlichen Statuscheck. Nach Ablauf dieser Zeit wird davon ausgegangen, dass Prüfungen, für die noch keine Abschlussmeldung vorliegt, fehlgeschlagen sind.

Erfordern erfolgreicher Bereitstellungen vor dem Mergen

Note

Diese Regel ist nicht für Regelsätze verfügbar, die auf Organisationsebene erstellt wurden.

Du kannst festlegen, dass Änderungen erfolgreich in bestimmten Umgebungen bereitgestellt werden müssen, bevor ein Branch gemergt werden kann. Du kannst diese Regel beispielsweise verwenden, um sicherzustellen, dass Änderungen erfolgreich in einer Stagingumgebung bereitgestellt werden, bevor die Änderungen in deinen Standardbranch gemergt werden.

Erfordern signierter Commits

Wenn du die erforderliche Commitsignierung für einen Branch aktivierst, können Mitwirkende und Bots nur Commits pushen, die für den Branch signiert und verifiziert wurden. Weitere Informationen findest du unter Informationen zur Verifizierung einer Commit-Signatur.

Verzweigungsschutzregeln und Regelsätze verhalten sich Beim Erstellen von Verzweigungen auf unterschiedliche Weise: Bei Regelsätzen werden nur die Commits überprüft, die nicht von anderen Verzweigungen aus zugänglich sind, während bei Verzweigungsschutzregeln keine signierten Commits überprüft werden; es sei denn, du schränkst Pushes ein, die passende Verzweigungen erstellen. In beiden Fällen werden beim Aktualisieren einer Verzweigung alle Commits im angegebenen Bereich überprüft, auch wenn ein Commit von anderen Verzweigungen aus erreichbar ist.

Bei beiden Methoden wird verified_signature? verwendet, um zu bestätigen, ob ein Commit über eine gültige Signatur verfügt. Wenn nicht, wird das Update nicht angenommen.

Note

  • Wenn du in deinen Kontoeinstellungen den wachsamen Modus aktiviert hast, der angibt, dass deine Commits immer signiert werden, werden alle von GitHub als „Teilweise überprüft“ identifizierten Commits für Branches genehmigt, die signierte Commits erfordern. Weitere Informationen zum wachsamen Modus findest du unter Anzeigen von Überprüfungsstatus für alle deine Commits.
  • Wenn eine Projektmitarbeiterin einen nicht signierten Commit an einen Branch pusht, der Commitsignaturen erfordert, muss ein Rebase für den Commit ausgeführt werden, damit eine verifizierte Signatur eingebunden und dann ein Push des neu geschriebenen Commits in den Branch erzwungen wird.

Du kannst jederzeit lokale Commits zum Branch übertragen, wenn die Commits signiert und verifiziert sind. Du kannst signierte und verifizierte Commits auch mithilfe eines Pull Requests auf GitHub Enterprise Cloud in den Branch mergen. Du kannst jedoch keinen Pull Request in den Branch auf GitHub Enterprise Cloud squashen und mergen, es sei denn, du bist Autor*in des Pull Requests. Du kannst Pull Requests lokal squashen und mergen. Weitere Informationen findest du unter Pull Requests lokal auschecken.

Weitere Informationen zu Mergemethoden findest du unter Informationen zu Merge-Methoden auf GitHub.

Anfordern eines Pull Requests vor dem Mergen

Du kannst anfordern, dass alle Änderungen am Zielbranch einem Pull Request zugeordnet werden. Der Pull Request muss nicht unbedingt genehmigt werden, aber er muss geöffnet werden.

Zusätzliche Einstellungen

Note

Hinweis: Wenn du Alte Pull Request-Genehmigungen verwerfen, wenn neue Commits gepusht werden und/oder Genehmigung des letzten überprüfbaren Pushs anfordern auswählst, schlägt das manuelle Erstellen des Mergecommits für einen Pull Request und das direkte Pushen an einen geschützten Branch fehl, es sei denn, der Mergeinhalt stimmt genau mit dem Merge überein, der von GitHub für den Pull Request generiert wurde.

Darüber hinaus wird die Genehmigung von Überprüfungen mit diesen Einstellungen als veraltet verworfen, wenn die Mergebasis nach der Übermittlung der Überprüfung neue Änderungen einführt. Die Mergebasis ist der Commit, der den letzten gemeinsamen Vorgänger zwischen dem Topic-Branch und dem Basisbranch darstellt. Wenn sich die Mergebasis ändert, kann der Pull Request erst zusammengeführt werden, wenn jemand die Arbeit erneut genehmigt.

Repositoryadministrator*innen oder benutzerdefinierte Rollen mit der Berechtigung „Repositoryregeln bearbeiten“ können verlangen, dass alle Pull Requests eine bestimmte Anzahl genehmigender Reviews erhalten sollen, bevor jemand den Pull Request in einem geschützten Branch zusammenführt. Du kannst die Genehmigung von Bewertungen von Personen mit Schreibberechtigungen im Repository oder von einem bestimmten Codebesitzer anfordern.

Wenn du erforderliche Reviews aktivierst, können Projektmitarbeiterinnen Änderungen an einem Branch nur über einen Pull Request pushen, der von der erforderlichen Anzahl von Reviewerinnen mit Schreibberechtigungen genehmigt wurde.

Wenn jemand bei einem Review die Option Änderungen anfordern auswählt, muss diese Person den Pull Request genehmigen, bevor der Pull Request gemergt werden kann. Wenn Reviewerinnen, die Änderungen an einem Pull Request anfordern, der nicht verfügbar ist, können alle Benutzerinnen mit Schreibberechtigungen für das Repository den blockierenden Review verwerfen.

Selbst nachdem alle erforderlichen Reviewer einen Pull Request genehmigt haben, können Mitarbeiter den Pull Request nicht mergen, wenn andere offene Pull Requests mit einem HEAD-Branch vorhanden sind, der auf denselben Commit mit ausstehenden oder abgelehnten Reviews verweist. Zuerst muss eine Person mit Schreibberechtigungen den blockierenden Review für den anderen Pull Request genehmigen oder schließen.

Optional kannst du veraltete Pull Request-Genehmigungen verwerfen, wenn Commits gepusht werden, die sich auf den diff (Unterschied) im Pull Request auswirken. GitHub zeichnet den Status des diff zu dem Zeitpunkt auf, zu dem ein Pull Request genehmigt wird. Dieser Zustand stellt die Änderungen dar, die der Reviewer genehmigt hat. Wenn sich der diff von diesem Zustand ändert (z. B. weil eine Mitwirkender neue Änderungen an den Pull Request-Branch pusht oder auf Branch aktualisieren klickt oder weil ein verwandter Pull Request in den Zielbranch gemergt wird), wird der genehmigende Review als veraltet geschlossen, und der Pull Request kann erst gemergt werden, wenn jemand die Arbeit noch mal genehmigt. Weitere Informationen zum Zielbranch findest du unter Informationen zu Pull Requests.

Optional kannst du Reviews von Codebesitzerinnen anfordern. In diesem Fall muss jeder Pull Request, der Inhalt mit Codebesitzerinnen ändert, von diesen Codebesitzerinnen genehmigt werden, bevor der Pull Request in den geschützten Branch gemergt werden kann. Beachten Sie, dass bei Code mit mehreren Besitzerinnen die Genehmigung eines Codebesitzers ausreicht, um diese Anforderung zu erfüllen. Weitere Informationen findest du unter Informationen zu Codeinhabern.

Optional kannst du die Zustimmung einer anderen als der letzten Person anfordern, die einen Push für einen Branch durchführt, bevor ein Pull Request gemergt werden kann. Das bedeutet, dass mindestens eine anderer autorisierter Reviewerin Änderungen genehmigt hat. Beispielsweise kann der bzw. die „letzte Reviewer*in“ überprüfen, ob die zuletzt vorgenommenen Änderungen Feedback aus anderen Reviews enthalten, und fügt keine neuen, nicht überprüften Inhalte hinzu.

Bei komplexen Pull Requests, die viele Reviews erfordern, kann die Anforderung einer Genehmigung von einer anderen Person als der letzten Person, die für den Push verantwortlich war, ein Kompromiss sein, der es nicht notwendig macht, alle veralteten Reviews zu verwerfen. Mit dieser Option werden „veraltete“ Reviews nicht verworfen, und der Pull Request verbleibt im genehmigten Status, bis eine andere Person als die Person, die die letzten Änderungen durchgeführt hat, ihn genehmigt. Benutzer, die einen Pull Request bereits überprüft haben, können ihn nach dem letzten Push erneut genehmigen, um diese Anforderung zu erfüllen. Wenn du Bedenken hast, dass Pull Request „gekapert“ werden (also nicht genehmigter Inhalt zu genehmigten Pull Requests hinzugefügt wird), ist es sicherer, die veralteten Reviews zu verwerfen.

Optional kannst du anfordern, dass alle Kommentare zum Pull Request geklärt sein müssen, bevor er in einen Branch gemergt werden kann. Auf diese Weise wird sichergestellt, dass vor dem Mergen alle Kommentare geklärt oder berücksichtigt wurden.

Anfordern bestandener Statuschecks vor dem Mergen

Mit erforderlichen Statuschecks wird sichergestellt, dass alle erforderlichen CI-Tests bestanden werden, bevor Mitarbeiter*innen Änderungen an einem Branch oder Tag vornehmen können, auf den bzw. das dein Regelsatz abzielt. Weitere Informationen findest du unter „Geschützte Branches konfigurieren“ und „Erforderliche Statuschecks aktivieren“. Weitere Informationen findest du unter Informationen zu Statuschecks.

Du kannst die Commitstatus-API verwenden, um externen Diensten das Markieren von Commits mit einem geeigneten Status zu ermöglichen. Weitere Informationen findest du unter REST-API-Endpunkte für Commitstatus.

Nach der Aktivierung erforderlicher Statuschecks müssen sie alle bestanden werden, bevor Projektmitarbeiter*innen Änderungen in den Branch oder das Tag mergen können.

Jede Person oder Integration mit Schreibberechtigungen für ein Repository kann den Status einer Statusüberprüfung im Repository festlegen, aber in manchen Fällen solltest du vielleicht nur eine Statusüberprüfung durch eine bestimmte GitHub App zulassen. Wenn Sie eine erforderliche Regel für die Statusprüfung hinzufügen, können Sie eine App als erwartete Quelle von Statusupdates auswählen. Die App muss mit der statuses:write-Berechtigung im Repository installiert sein, muss kürzlich eine Überprüfungsausführung übermittelt haben und einem bereits vorhandenen erforderlichen Statuscheck im Regelsatz zugeordnet sein. Wenn der Status von einer anderen Person oder Integration festgelegt wird, ist das Mergen nicht zulässig. Wenn du „Beliebige Quelle“ auswählst, kannst du die Autor*innen jedes Status weiterhin manuell überprüfen (im Mergefeld aufgeführt).

Note

Bei Statusprüfungen auf Organisationsebene muss die App mit der statuses:write-Berechtigung installiert werden. Nur Apps mit dieser Berechtigung werden beim Konfigurieren von Regelsätzen auf Organisationsebene angezeigt.

Du kannst dir die erforderlichen Statuschecks entweder als „loose“ (locker) oder als „strict“ (streng) vorstellen. Die Art der erforderlichen Statuschecks bestimmt, ob dein Branch vor dem Zusammenführen auf dem aktuellen Stand mit dem Basisbranch sein muss.

Art des erforderlichen StatuschecksEinstellungMerge-AnforderungenÜberlegungen
StrictDas Kontrollkästchen Aktualität von Branches vor dem Mergen erfordern ist aktiviert.Der Topic-Branch muss vor dem Mergen auf dem Stand des Basisbranchs sein.Dies ist das Standardverhalten für erforderliche Statuschecks. Weitere Builds können erforderlich sein, da du den Hauptbranch auf den neuesten Stand bringen musst, nachdem andere Projektmitarbeiter*innen den Zielbranch aktualisiert haben.
LockerDas Kontrollkästchen Aktualität von Branches vor dem Mergen erfordern ist nicht aktiviert.Der Branch muss vor dem Mergen nicht auf dem Stand des Basisbranchs sein.Es sind weniger Builds erforderlich, da du den Head-Branch nicht auf den neuesten Stand bringen musst, nachdem andere Mitarbeiter Pull Requests überführt haben. Statuschecks schlagen nach dem Zusammenführen deines Branches möglicherweise fehl, wenn inkompatible Änderungen am Basisbranch vorliegen.
DeaktiviertDas Kontrollkästchen Durchlaufen von Statusüberprüfungen vor dem Mergen erfordern ist nicht aktiviert.Für den Branch gelten keine Merge-Einschränkungen.Wenn die erforderlichen Statuschecks nicht aktiviert sind, können Mitarbeiter den Branch unabhängig von seinem Stand gegenüber dem Basisbranch jederzeit zusammenführen. Die Wahrscheinlich inkompatibler Änderungen erhöht sich dadurch jedoch.

Informationen zur Problembehandlung findest du unter Fehlerbehebung von erforderlichen Statuschecks.

Erzwungene Pushs blockieren

Du kannst verhindern, dass Benutzer*innen das Pushen an die anvisierten Branches oder Tags erzwingen. Diese Regel ist standardmäßig aktiviert.

Wenn jemand Pushvorgänge auf einen Branch oder ein Tag erzwingt, werden Commits, auf denen andere Mitarbeiter*innen ihre Arbeit aufgebaut haben, möglicherweise aus dem Verlauf des Branchs oder Tags entfernt. Das kann zu Mergekonflikten oder beschädigten Pull Requests führen. Ein erzwungener Push kann auch zum Löschen von Branchs oder zum Verweisen eines Branches auf Commits verwendet werden, die in einem Pull Request nicht genehmigt wurden.

Durch das Aktivieren erzwungener Pushs wird keine andere Regel überschrieben. Wenn ein Branch beispielsweise einen linearen Commit-Verlauf verlangt, kannst du keine Merge-Commit-Pushes zu diesem Branch erzwingen.

Workflows müssen vor der Zusammenführung weitergegeben werden

Regelsatzworkflows können auf Organisationsebene konfiguriert werden, so dass Workflows vor dem Zusammenführen von Pullanforderungen übergeben werden müssen. Weitere Informationen finden Sie unter „Erstellen von Regelsätzen für Repositorys in deiner Organisation.“

Weitere Informationen zur Problembehandlung allgemeiner Probleme mit Konfigurationseinstellungen des Regelsatz-Workflow finden Sie unter „Problembehandlung für Regeln.“

Verwenden einer Workflowdatei

Um diese Regel anwenden zu können, musst du zuerst eine Workflowdatei erstellen. Die Workflowdatei muss sich in einem Repository befinden, das der Sichtbarkeit der Repositorys entspricht, in denen du sie ausführen möchtest. Ein öffentlicher Workflow kann in jedem Repository in deiner Organisation ausgeführt werden, ein interner Workflow kann nur auf internen und privaten Repositorys ausgeführt werden, und ein privater Workflow kann nur auf privaten Repositorys ausgeführt werden. Weitere Informationen findest du unter Informationen zu Workflows.

Wenn sich die Workflow-Datei in einem internen oder privaten Repository befindet und du den Workflow in anderen Repositorys im Unternehmen verwenden möchtest, musst du den Zugriff auf den Workflow von außerhalb des Repositorys erlauben. Weitere Informationen findest du unter „Zulassen des Zugriffs auf Komponenten in einem privaten Repository“ oder „Zulassen des Zugriffs auf Komponenten in einem internen Repository“.

Wenn Sie diese Regel zu einem Regelsatz hinzufügen, geben Sie in den Organisationseinstellungen das Quell-Repository und den Workflow an, den Sie erzwingen möchten.

Verwenden des Modus „Auswerten“ für Regelsatzworkflows

Wenn ein Regelsatzworkflow im Modus „Auswerten“ läuft und erfolgreich ist, können Sie den Regelsatz-Workflow in den Modus "Aktiv" versetzen und Ihren Pull Request zusammenführen, ohne einen neuen Workflow-Lauf auszulösen.

Wenn Sie einen Pull Request öffnen, bevor Sie den Regesatz im Modus „Auswerten“ erstellen, können Sie den Pull Request trotzdem zusammenführen, da der Regelsatz nicht erzwungen wird.

Weitere Informationen zu Erzwingstatus finden Sie unter „Erstellen von Regelsätzen für ein Repository.“

Unterstützte Ereignisauslöser

Regelsatzworkflows unterstützen die Verwendung der Ereignisse pull_request, pull_request_target und merge_group. Daher müssen Sie ein oder mehrere dieser Ereignisse im on: Abschnitt des Workflows angeben, damit der Workflow von einem Regelsatz ausgeführt werden kann.

Alle Filter, die Sie für die unterstützten Ereignisse angeben, werden ignoriert – branches, branches-ignore, paths, types usw. Der Workflow wird nur und immer durch die Standardaktivitätstypen der unterstützten Ereignisse ausgelöst.

EreignisStandardaktivitätstypen
pull_requestopened, synchronize, reopened
pull_request_targetopened, synchronize, reopened
merge_groupchecks_requested

Adressieren spezifischer Verzweigungen mit Ihrem Regelsatzworkflow

Wenn Sie diese Regel anwenden, werden Direct Pushs blockiert, da die Regelsatzworkflows als Teil der Pull Request und der Zusammenführungswarteschlange ausgeführt werden. Aus diesem Grund sollten Sie diese Regel nicht auf einen Regelsatz anwenden, der auf alle Verzweigungen im Repository ausgerichtet ist.

Diese Regel sollte nur zu Regelsätzen hinzugefügt werden, die auf Verzweigungen abzielen, bei denen alle Änderungen an der Verzweigung von Pull Requests ausgeführt werden.

Metadateneinschränkungen

Hinweise:

  • Das Hinzufügen von Metadateneinschränkungen kann für Personen, die zu deinem Repository beitragen, zu Beeinträchtigungen führen. Bevor du einen Regelsatz mit Metadateneinschränkungen aktivierst, kannst du den Erzwingungsstatus „Auswerten“ für deinen Regelsatz auswählen, um die Auswirkungen von Metadateneinschränkungen zu testen, ohne Mitwirkende zu beeinträchtigen. Weitere Informationen zu Metadateneinschränkungen findest du unter Verfügbare Regeln für Regelsätze.
  • Metadateneinschränkungen sollen die Konsistenz zwischen Commits in deinem Repository erhöhen. Sie sind nicht dazu bestimmt, Sicherheitsmaßnahmen wie die Anforderung eines Code Reviews über Pull Requests zu ersetzen.
  • Wenn du einen Squashmerge für einen Branch ausführst, müssen alle Commits in diesem Branch alle Metadatenanforderungen für den Basisbranch erfüllen.

Organisationen mit einem GitHub Enterprise-Plan können auf zusätzliche Regeln zugreifen, um zu steuern, wie Commitmetadaten formatiert werden müssen. Du kannst Literalzeichenfolgen oder die Syntax regulärer Ausdrücke verwenden, um ein Muster zu definieren, dem die Commitmetadaten entsprechen müssen. Du kannst beispielsweise verlangen, dass Commitnachrichten eine GitHub-Problemnummer enthalten oder dass der Committer oder Autor über eine E-Mail-Adresse verfügt, die auf @octoorg.com endet. Du kannst auch das Format neuer Branchnamen und Tagnamen steuern. Eine Auswahl nützlicher regulärer Ausdrücke für Commitmetadaten findest du unter Erstellen von Regelsätzen für ein Repository.

Wenn ein Mitwirkender versucht, einen Branch oder ein Tag mit einem Commit zu aktualisieren, der nicht deinen Anforderungen entspricht, wird dem Mitwirkenden ein Fehler angezeigt, der ihm mitteilt, was mit dem Commit nicht in Ordnung war. Dieser Fehler kann sowohl in der Befehlszeile angezeigt werden, wenn der Benutzer pusht, als auch in GitHub.com, wenn der Benutzer versucht, einen Commit durchzuführen oder einen Pull Request zu mergen. Commits sind in Git unveränderlich: Sobald Mitwirkende einen Commit erstellt hat, können die Metadaten des Commits nicht bearbeitet werden, sodass sie möglicherweise eine Rebase ausführen müssen, um ihren Commitverlauf mit neuen Commits neu zu schreiben, bevor sie ihre Arbeit erfolgreich zum Repository beitragen können.

Metadateneinschränkungen sind nützlich, um die Konsistenz zwischen den Commits im Verlauf eines Branchs zu erzwingen. Dies kann nützlich sein, um die Einhaltung bewährter Methoden zu erzwingen (z. B. die Spezifikation für konventionelle Commits) oder für die Integration in Tools, die auf Commitmetadaten angewiesen sind. Beispielsweise ist es einfacher, Skripts basierend auf dem Inhalt einer Commitnachricht auszuführen, wenn jede Nachricht einem vorhersagbaren Format entspricht.

Wichtige Überlegungen zu Metadateneinschränkungen

Metadateneinschränkungen blockieren „ref updates“. Wenn Mitwirkende eine Arbeit pushen, die einen Commit enthält, der die Anforderungen nicht erfüllt, wird der Push nicht abgelehnt, aber der Branch oder das Tag, auf den sie abzielen, wird nicht aktualisiert. Technisch gesehen gelangen die Commits weiterhin in dein Repository: Die Commits sind „abrufbar“ (du kannst zu ihnen in deinem Repository navigieren), aber nicht „erreichbar“ (sie sind nicht mit dem Verlauf eines Branchs oder Tags verbunden). Wenn der Push des Mitwirkenden auch die Arbeit an anderen Branches oder Tags mit Commits enthält, die die Anforderungen dieser Branches oder Tags erfüllen, werden diese Verweise erfolgreich aktualisiert.

Metadateneinschränkungen können Unstimmigkeiten für Personen erhöhen, die zu einem Repository beitragen. Wenn du Metadateneinschränkungen festlegst, solltest du dies im Allgemeinen für eine begrenzte Anzahl von Branches tun, um Beeinträchtigungen der täglichen Arbeit der Mitwirkenden zu vermeiden. Anstatt beispielsweise konsistente Commitnachrichten für einen Topic-Branch anzufordern, an dem Mitwirkende arbeiten, solltest du konsistente Commitnachrichten nur für main und dann Pull Requests für main anfordern.

Wenn du Squashmerges verwendest, musst du beachten, dass Metadateneinschränkungen vor dem Merge ausgewertet werden, sodass alle Commits für den Pull Request die Anforderungen erfüllen müssen. Bei Metadateneinschränkungen, die Committer-E-Mails einschließen, muss das Muster auch noreply@github.com für Squashmengen enthalten, um die Einschränkung zu erfüllen.

Wenn du einem vorhandenen Branch oder Tag Metadateneinschränkungen hinzufügst, werden die Regeln für neue Commits erzwungen, die ab diesem Zeitpunkt an den Branch oder das Tag gepusht werden, aber sie werden nicht für den vorhandenen Verlauf des Branchs oder Tags erzwungen.