Verfügbare Regeln für Regelsätze

Sie können Regelsätze für Branches oder Tags erstellen, um zu kontrollieren, wie Benutzer*innen mit ausgewählten Branches und Tags in einem Repository interagieren können. Sie können auch Push-Regelsätze erstellen, um Pusheingaben an ein privates oder internes Repository zu blockieren und das gesamte Forknetzwerk dieses Repositorys zu blockieren.

Wenn du einen Regelsatz erstellst, kannst du bestimmten Benutzerinnen erlauben, die Regeln darin zu umgehen. Das können Benutzerinnen mit bestimmten Rollen, bestimmte Teams oder GitHub Apps sein.

Für Push-Regelsätze gelten Umgehungsberechtigungen für ein Repository und das gesamte Forknetzwerk des Repositorys. Dies bedeutet, dass die einzigen Benutzer, die diesen Regelsatz für jedes Repository im gesamten Forknetzwerk dieses Repositorys umgehen können, die Benutzer sind, die dieses Regelsatz im Stamm-Repository umgehen können.

Weitere Informationen zum Erstellen von Regelsätzen und Umgehungsberechtigungen findest du unter Erstellen von Regelsätzen für ein Repository.

Erstellungen einschränken

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 Erzwingen eines linearen Commitverlaufs kann verhindert werden, dass Projektmitarbeiter*innen Merge-Commits an die anvisierten Branches oder Tags pushen. Das bedeutet, dass alle Pull Requests, die in den Branch oder das Tag integriert sind, einen Squash-Merge oder einen Rebase-Merge 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 finden Sie unter Pull-Request-Merges konfigurieren.

Erforderlichkeit von Zusammenführungswarteschlangen

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 Merge-Warteschlange.

Zusätzliche Einstellungen

Sie können verschiedene Einstellungen für Ihre Regel für die Zusammenführungswarteschlange konfigurieren.

•         **Merge-Methode:** Methode, die beim Zusammenführen von Änderungen aus Pull Requests verwendet werden soll.
  

•         **Bauen Sie die Nebenläufigkeit auf:** Begrenzen Sie die Anzahl der Pull Requests, die in die Warteschlange eingereiht werden und gleichzeitig Überprüfungen und Workflow-Durchläufe anfordern.
  

  • Diese Einstellung steuert, wann die Merge-Warteschlange das merge_group.checks_requested Webhook-Ereignis versendet, das GitHub Actions-Workflows auslöst, die für die Ausführung auf merge_group konfiguriert sind. Weitere Informationen finden Sie unter Webhook-Ereignisse und Webhook-Nutzlasten.
  • Wenn beispielsweise fünf Pull Requests zur Warteschlange hinzugefügt wurden und die Einstellung der Buildparallelität 3 ist, sendet die Mergewarteschlange das checks_requested-Ereignis für die ersten drei Pull Requests. Sobald die Mergewarteschlange ein Ergebnis für einen dieser Pull Requests empfängt, wird das Ereignis für den 4. Pull Request ausgelöst, und so weiter.

•         **Minimale/maximale Gruppengröße**: Die Anzahl der Pull Requests, die in einer Gruppe zusammengeführt werden.
  

•         **Wartezeit bis zur Erreichung der minimalen Gruppengröße (Minuten):** Die Zeit, die die Mergewarteschlange nach dem Hinzufügen des ersten Pull Requests wartet, damit die minimale Gruppengröße erreicht wird. Nach Ablauf dieser Zeit wird die minimale Gruppengröße ignoriert und eine kleinere Gruppe zusammengeführt.
  

•         **Erfordern Sie, dass alle Warteschlangeneinträge die erforderlichen Prüfungen bestehen**
  

  • 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 am Kopf der Merge-Gruppe, 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.
  

Erfolgreiche Bereitstellungen sind erforderlich vor dem Mergen

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 Staging-Umgebung bereitgestellt werden, bevor die Änderungen in den Standard-Branch zusammengeführt werden.

Signierte Commits erforderlich

Wenn du die erforderliche Commitsignierung für einen Branch aktivierst, können Mitwirkende nur Commits auf den Branch pushen, die signiert und verifiziert sind. Weitere Informationen finden Sie 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 eines Branches alle Commits im angegebenen Bereich überprüft, auch wenn ein Commit von anderen Branches 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.

Du kannst jederzeit lokale Commits zum Branch übertragen, wenn die Commits signiert und verifiziert sind. Du kannst keine Pull Requests in den Branch auf GitHub mergen. Pull Requests kannst du lokal mergen. Weitere Informationen finden Sie unter Pull Requests lokal auschecken.

Fordern Sie einen Pull Request an, bevor Sie zusammenführen

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

Die Repositoryadministration oder benutzerdefinierte Rollen mit der Berechtigung „edit repository rules“ können verlangen, dass alle Pull Requests eine bestimmte Anzahl genehmigender Reviews erhalten sollen, bevor der Pull Request in einem geschützten Branch zusammengeführt werden kann. 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 eine Reviewerin, derdie Änderungen an einem Pull Request anfordert, nicht verfügbar ist, können alle Benutzerinnen mit Schreibberechtigung für das Repository die blockierende Überprüfung aufheben.

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.

Optionalerweise kannst du veraltete Genehmigungen von Pull-Anfragen verwerfen, wenn Commits gepusht werden, die den Diff in der Pull-Anfrage betreffen. 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 in diesem Zustand ändert (z. B. weil ein Mitwirkender neue Änderungen in den Pull-Request-Branch pusht oder auf Branch aktualisieren klickt, oder weil ein verwandter Pull Request in den Zielbranch gemergt wird), wird die genehmigende Überprüfung als veraltet betrachtet, und der Pull Request kann erst gemergt werden, nachdem jemand die Arbeit erneut genehmigt hat. Weitere Informationen zum Ziel-Branch finden Sie 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 finden Sie unter Informationen zu Code-Eigentümern.

Optional kannst du die Zustimmung von jemand anderem als der Person einholen, die zuletzt einen Push auf den Branch ausgeführt hat, bevor ein Pull Request integriert 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.

Optional kannst du den Mergetyp „merge“, „squash“ oder „rebase“ vorschreiben. Dies bedeutet, dass die Ziel-Branches nur basierend auf dem zugelassenen Typ zusammengeführt werden können. Wenn für das Repository eine Mergemethode deaktiviert ist und die Regelvorgabe eine andere Methode benötigt, wird der Zusammenführungsvorgang blockiert. Weitere Informationen findest du unter Informationen zu Zusammenführungsmethoden auf GitHub.

Erforderlich machen, dass Statusüberprüfungen vor dem Zusammenführen bestanden werden.

Mit erforderlichen Statuschecks wird sichergestellt, dass alle erforderlichen CI-Tests bestanden werden, bevor Benutzer Änderungen an einem Branch oder Tag vornehmen können, auf den dein Regelsatz abzielt. Erforderliche Statusprüfungen können Überprüfungen oder Status sein. Weitere Informationen finden Sie 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 finden Sie unter REST-API-Endpunkte für Commit-Status.

Nach der Aktivierung erforderlicher Statuschecks müssen sie alle bestanden werden, bevor Projektmitarbeiter*innen Änderungen in den Branch oder das Tag mergen können. Optional kannst du „Keine Statusüberprüfungen bei der Erstellung erforderlich“ auswählen, wenn du die Erstellung von Verzweigungen unabhängig vom Ergebnis einer Statusüberprüfung zulassen möchtest.

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 Sie "jede Quelle" auswählen, können Sie den Autor jedes Statuses weiterhin manuell überprüfen, der im Zusammenführungsfeld aufgeführt ist.

Weitere Informationen zur Problembehandlung beim Konfigurieren von Statusüberprüfungen in Regelsätzen findest du unter Fehlerbehebung von Regeln.

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

Art des erforderlichen Statuschecks	Einstellungen	Merge-Anforderungen	Überlegungen

          **Strict** | Das Kontrollkästchen **Aktualität von Branches vor dem Mergen erfordern** ist aktiviert. | Der Topic-Branch **muss** auf dem aktuellen Stand des Basis-Branches sein, bevor er zusammengeführt wird. | Dies ist das Standardverhalten für erforderliche Statuschecks. Weitere Builds können erforderlich sein, da du den Hauptzweig auf den neuesten Stand bringen musst, nachdem andere Mitwirkende den Zielzweig aktualisiert haben.|

| Lose | Das 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 aktualisieren musst, nachdem andere Teammitglieder Pull Requests überführt haben. Status-Checks schlagen möglicherweise fehl, nachdem du deinen Branch zusammengeführt hast, wenn inkompatible Änderungen am Basis-Branch vorliegen. | | Deaktiviert | Das 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 Statusprüfungen nicht aktiviert sind, können Mitwirkende den Branch jederzeit zusammenführen, unabhängig davon, ob er auf dem neuesten Stand mit dem Basis-Branch ist. Die Wahrscheinlichkeit inkompatibler Änderungen erhöht sich dadurch.

Weitere Informationen zur Fehlerbehebung bei Statusüberprüfungen findest du unter Fehlerbehebung von erforderlichen Statuschecks.

Blockiere erzwungene Pushes

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

Wenn jemand einen Branch oder ein Tag mit einem Force-Push überschreibt, werden Commits, auf denen andere Mitwirkende ihre Arbeit aufgebaut haben, möglicherweise aus der Historie des Branches oder Tags gelöscht. 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.

Du kannst erzwungene Pushs für einen Branch nicht aktivieren, wenn Websiteadministrator*innen erzwungene Pushs an alle Branches in deinem Repository blockiert haben. Weitere Informationen finden Sie unter Richtlinien zur Verwaltung von Repositories in Ihrem Unternehmen erzwingen.

Wenn eine Websiteadministratorin erzwungene Pushs nur auf den Standardbranch blockiert hat, können Sie erzwungene Pushs trotzdem für jeden anderen Branch oder Tag aktivieren.

Erforderlich sind code scanning Ergebnisse

Wenn Ihre Repositorys mit code scanning konfiguriert sind, können Sie Regelsätze verwenden, um zu verhindern, dass Pull Requests zusammengeführt werden, wenn eine der folgenden Bedingungen erfüllt ist:

• Ein Pflichttool entdeckt eine code scanning-Warnung mit einem Schweregrad, der im Regelsatz definiert ist.
• Die Analyse eines erforderlichen Tools wird noch ausgeführt.
• Für das Repository ist kein erforderliches Tool konfiguriert.

Weitere Informationen finden Sie unter Festlegen des Zusammenführungsschutzes für Codeüberprüfung. Weitere allgemeine Informationen zu code scanning findest du unter Informationen zu Codescans.

Workflows müssen vor der Zusammenführung bestehen

Regelsatzworkflows können auf Organisationsebene oder Unternehmensebene konfiguriert werden, damit Workflows diese Überprüfung erfolgreich abschließen müssen, bevor Pull Requests gemergt werden. Weitere Informationen finden Sie unter Erstellen von Regelsätzen für Repositorys in deiner Organisation.

Weitere Informationen zur Problembehandlung bei Konfigurationseinstellungen für allgemeine Regelsatzworkflows findest du unter Fehlerbehebung von 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 finden Sie unter 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 internen Repository oder Zulassen des Zugriffs auf Komponenten in einem privaten 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 Erzwingungsstatus findest du 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.

Ereignis	Standardaktivitätstypen
pull_request	opened, synchronize, reopened
pull_request_target	opened, synchronize, reopened
merge_group	checks_requested

Zielgerichtetes Anvisieren spezifischer Verzweigungen mit Ihrem Workflow für Regelsätze

Wenn Sie diese Regel anwenden, werden Direct-Pushes blockiert, da die Regelsatzworkflows als Teil der Pull-Request- und 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 Branches abzielen, bei denen alle Änderungen an dem Branch durch Pull Requests ausgeführt werden.

Optional kannst du „Keine Workflowüberprüfungen bei der Erstellung erforderlich“ auswählen, wenn du die Erstellung von Verzweigungen unabhängig vom Ergebnis einer Statusüberprüfung zulassen möchtest.

Metadateneinschränkungen

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, das den Anforderungen nicht entspricht, wird dem Mitwirkenden ein Fehler angezeigt, der erklärt, was mit dem Commit nicht stimmt. 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 Branches zu gewährleisten. 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. Du kannst Metadateneinschränkungen als Alternative zum Einrichten von benutzerdefinierten Pre-Receive-Hook-Skripts verwenden. Weitere Informationen findest du unter [AUTOTITLE] (/admin/policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks).

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 Arbeit an anderen Branches oder Tags mit Commits enthält, die die Anforderungen dieser Branches oder Tags erfüllen, dann werden diese Verweise erfolgreich aktualisiert.

Metadateneinschränkungen können Reibung für Personen erzeugen, 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 Commit-Nachrichten für jeden beliebigen Topic-Branch zu verlangen, an dem Mitwirkende arbeiten, solltest du konsistente Commit-Nachrichten nur für main verlangen. Danach fordere Pull Requests in main an.

Wenn du Squash-Merges verwendest, werden die einzelnen Commits im Pull Request ignoriert. Stattdessen werden Einschränkungen nur anhand der Metadaten des einzelnen, resultierenden Merge-Commits überprüft. Die Pull Request-Seite überprüft diese Informationen, bevor der Merge zulässig ist, und stellt sicher, dass der endgültige Commit konform ist. Bei Metadateneinschränkungen, die Committer-E-Mails einschließen, muss das Muster auch noreply@github.com für Squash-Merges 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, die ab diesem Zeitpunkt an den Branch oder das Tag gepusht werden, durchgesetzt, aber sie werden nicht auf die bestehende Historie des Branchs oder Tags angewendet.

Dateipfade einschränken

Verhindern, dass Commits, die Änderungen in angegebenen Dateipfaden enthalten, an das Repository übertragen werden. Das Limit beträgt 200 Einträge und bis zu 200 Zeichen in jedem Eintrag.

Sie können fnmatch-Syntax hierfür verwenden. Eine Einschränkung, die zum Beispiel auf test/demo/**/* zielt, verhindert Pushes an Dateien oder Ordner im test/demo/-Verzeichnis. Eine Einschränkung mit Ziel test/docs/pushrules.md verhindert Pushs, speziell an die pushrules.md-Datei im test/docs/-Verzeichnis. Weitere Informationen finden Sie unter Erstellen von Regelsätzen für ein Repository.

Dateipfadlänge einschränken

Verhindern, dass Commits, die Dateipfade enthalten, die ein angegebenes Zeichenlimit überschreiten, an das Repository verschoben werden.

Einschränken von Dateierweiterungen

Verhindern, dass Commits, die Dateien mit angegebenen Dateierweiterungen enthalten, an das Repository übertragen werden. Das Limit beträgt 200 Eintragungen und bis zu 200 Zeichen pro Eintragung.

Dateigröße einschränken

Verhindern, dass Commits, die eine angegebene Dateigrößenbeschränkung überschreiten, an das Repository übertragen werden.