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 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 finden Sie unter Pull-Request-Merges konfigurieren.

Erfordern erfolgreicher Bereitstellungen 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.

Erfordern signierter Commits

Wenn du die erforderliche Commitsignierung für einen Branch aktivierst, können Mitwirkende und Bots 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 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.

Hinweis

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. Sie können signierte und verifizierte Commits auch mithilfe eines Pull Request im Branch mergen. Sie können jedoch keinen Pull Request in den Branch auf GitHub squashen und mergen, es sei denn, Sie sind Autor*in des Pull Requests. Sie können Pull Requests lokal squashen und mergen. Weitere Informationen finden Sie unter Pull Requests lokal auschecken.

Weitere Informationen zu Mergemethoden findest du unter Informationen zu Zusammenführungsmethoden auf GitHub.

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

Hinweis

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.

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.

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 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. Informationen zur Zielverzweigung 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 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 der Regelsatz eine andere Methode benötigt, wird der Merge blockiert. Weitere Informationen findest du unter Informationen zu Zusammenführungsmethoden auf GitHub.

Erforderliche Reviewer

Optional können Sie eine Überprüfung oder Genehmigung von bestimmten Teams anfordern, wenn eine Pullanforderung bestimmte Dateien oder Verzeichnisse ändert. Sie können bis zu 15 verschiedene Teams angeben, und für jedes Team können Sie eine bestimmte Anzahl von Genehmigungen von Teammitgliedern anfordern.

Mit dem Dropdown-Menü "Reviewer" können Sie jedes Team auswählen, das sich im Geltungsbereich befindet, in dem die Regel definiert wird.

        **Organisationsweite Regeln**: Das Team muss zur Organisation gehören.

        **Regeln auf Repositoryebene**: Das Team muss zur Organisation gehören, die das Repository besitzt.

Diese Regel ist in benutzereigenen Repositorys nicht verfügbar, da sie keine Teams enthalten.

Erforderliche Genehmigungen können von 0 (Null) auf 10 festgelegt werden. Das Anfordern von Nullgenehmigungen bedeutet, dass das Team zur Sichtbarkeit hinzugefügt wird, aber das Team muss die Anforderung nicht genehmigen.

Für jedes Team können Sie eine Liste von Dateimustern angeben, die bestimmt, auf welche Dateien die Einstellung angewendet wird. Das Format dieser Dateiliste ist identisch mit einer Standarddatei .gitignore :

Ein Muster, das mit einem Ausrufezeichen (!) beginnt, ist eine Negation. Dies führt dazu, dass Pfade, die früheren Mustern entsprechen, keine Genehmigungen erfordern.
Muster werden in der angegebenen Reihenfolge abgeglichen, sodass negierte Muster „nicht übereinstimmende“ Dateien aufweisen können, die den vorherigen Regeln entsprachen.

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 Mitarbeiter*innen Änderungen an einem Branch oder Tag vornehmen können, auf den bzw. das dein Regelsatz abzielt. Bei erforderlichen Statuschecks kann es sich um Überprüfungen oder Status handeln. 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.

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** 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 Hauptzweig auf den neuesten Stand bringen musst, nachdem andere Mitwirkende den Zielzweig aktualisiert haben.|

| Loose | 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 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. | | 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 Statuschecks nicht aktiviert sind, können Mitarbeiter den Branch unabhängig von seinem Stand gegenüber dem Basisbranch jederzeit zusammenführen. Die Wahrscheinlichkeit inkompatibler Änderungen erhöht sich dadurch.

Weitere Informationen zur Fehlerbehebung bei Statusüberprüfungen 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 Branchs 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.

Erfordern von code scanning-Ergebnissen

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.

Codequalitätsergebnisse erforderlich

Wenn Ihre Repositories mit GitHub Code Quality konfiguriert sind, können Sie Regelsätze verwenden, um Pull Requests daran zu hindern, zusammengeführt zu werden, wenn eine der folgenden Bedingungen erfüllt ist:

Die Analyse wird noch ausgeführt.
Die Analyse schlägt aus irgendeinem Grund fehl, z. B.: Sie haben Ihr Budget für Aktionsminuten erschöpft.
Code Quality hat ein Ergebnis mit einem Schweregrad auf der im Regelsatz definierten Ebene oder mit einem höheren Schweregrad gefunden.

Weitere Informationen findest du unter Informationen zu GitHub Codequalität und Festlegen von Schwellenwerten für die Codequalität für Pullanforderungen.

Dateipfade einschränken

Verhindern, dass Commits, die Änderungen in angegebenen Dateipfaden enthalten, an das Repository übertragen werden. Der Grenzwert liegt bei 200 Einträgen 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.