Informationen zu Regelsätzen

Informationen zu Regelsätzen

Ein Regelsatz ist eine benannte Liste von Regeln, die für ein Repository oder für mehrere Repositorys in einer Organisation gilt. Sie können über bis zu 75 Regelsätzen pro Repository und 75 organisationsweite Regelsätze verfügen.

Wenn du einen Regelsatz erstellst, kannst du bestimmten Benutzerinnen erlauben, die Regeln darin zu umgehen. Dabei kann es sich um Benutzerinnen mit einer bestimmten Rolle, z. B. Repositoryadministrator, oder um bestimmte Teams oder GitHub Apps handeln. Weitere Informationen zum Gewähren von Umgehungsberechtigungen findest du unter Erstellen von Regelsätzen für ein Repository.

Du kannst für Organisationen mit einem GitHub Enterprise-Plan auf Organisationsebene Regelsätze für mehrere Repositorys in deiner Organisation einrichten. Weitere Informationen findest du unter Verwalten von Regelsätzen für Repositorys in deiner Organisation.

Sie können Regelsätze verwenden, um Verzweigungen oder Tags in einem Repository als Ziel zu verwenden oder Pushes an ein Repository und das gesamte Forknetzwerk des Repositorys zu blockieren.

Mit der delegierten Umgehung von Push-Regelsätzen können Sie steuern, wer den Push-Schutz umgehen kann und welche gesperrten Pushs zugelassen werden sollen.

Mit delegierter Umgehung müssen Mitwirkende eines Repositorys „Rechte umgehen“ anfordern, wenn Commits mit eingeschränktem Inhalt übertragen werden. Die Anforderung wird an eine bestimmte Gruppe von Prüfern gesendet, die die Anforderung zum Umgehen der Pushregeln genehmigen oder verweigern.

Wenn die Anforderung, Pushregeln zu umgehen, genehmigt wird, kann der Mitwirkende den Commit, der den eingeschränkten Inhalt enthält, pushen. Wenn die Anforderung abgelehnt wird, muss der Mitwirkende den Inhalt aus den Commits) entfernen, die die eingeschränkten Inhalte enthalten, bevor er es erneut veröffentlicht.

Um die delegierte Umgehung zu konfigurieren, erstellen Organisationsbesitzer oder Repositoryadministratoren zuerst eine „Umgehungsliste.“ Die Umgehungsliste umfasst bestimmte Rollen und Teams, z. B. Team- oder Repositoryadministratoren, die Anforderungen zum Umgehen des Pushschutzes überwachen. Weitere Informationen findest du unter Verwalten von Regelsätzen für Repositorys in deiner Organisation und unter Informationen zu Regelsätzen.

Verzweigungs- und Tag-Rulesätze

Du kannst Regelsätze erstellen, um zu steuern, wie Benutzerinnen mit ausgewählten Branches und Tags in einem Repository interagieren können. Du kannst z. B. steuern, wer Commits an einen bestimmten Branch pushen kann, wie Commits formatiert werden müssen oder wer ein Tag löschen oder umbenennen kann. Beispielsweise kannst du einen Regelsatz für den Branch feature deines Repositorys einrichten, der signierte Commits erfordert und erzwungene Pushs für alle Benutzer außer Repositoryadministratorinnen blockiert.

Für jeden von dir erstellten Regelsatz gibst du an, für welche Branches oder Tags in deinem Repository oder für welche Repositorys in deiner Organisation der Regelsatz gilt. Du kannst fnmatch-Syntax verwenden, um ein Muster für bestimmte Branches, Tags und Repositorys zu definieren. Du kannst z. B. das Muster releases/**/* verwenden, um alle Branches in deinem Repository als Ziel zu verwenden, deren Name mit der Zeichenfolge releases/ beginnt. Weitere Informationen zur fnmatch-Syntax findest du unter Erstellen von Regelsätzen für ein Repository.

Pushregelsätze

Mit Pushregelsätzen können Sie Pushes an ein privates oder internes Repository blockieren und das gesamte Forknetzwerk dieses Repositorys basierend auf Dateierweiterungen, Dateipfadlängen, Datei- und Ordnerpfaden und Dateigrößen blockieren.

Pushregeln erfordern keine Verzweigungsadressierung, da sie für jeden Push an das Repository gelten.

Push-Regelsätze ermöglichen Folgendes:

• Einschränken von Dateipfaden: Verhindern Sie bei Commits, die Änderungen in angegebenen Dateipfaden enthalten, dass sie gepusht werden.

  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 findest du unter Erstellen von Regelsätzen für ein Repository.

• Dateipfadlänge einschränken: Verhindern Sie Commits, die Dateipfade enthalten, die ein angegebenes Zeichenlimit überschreiten, per Push verschoben werden.

• Einschränken von Dateierweiterungen: Verhindern Sie Commits, die Dateien mit angegebenen Dateierweiterungen enthalten, pushen.

• Dateigröße einschränken: Verhindern Sie Commits, die eine angegebene Dateigrößenbeschränkung überschreiten, verschoben werden.

Informationen zu Pushregelsätzen für Fork-Repositorys

Pushregeln gelten für das gesamte Forknetzwerk für ein Repository, um sicherzustellen, dass jeder Einstiegspunkt im Repository geschützt ist. Wenn Sie beispielsweise ein Repository verzweigen, das Push-Regelsätze aktiviert hat, gelten dieselben Push-Regelsätze auch für Ihr Fork-Repository.

Bei einem Fork-Repository sind die einzigen Personen, die über Umgehungsberechtigungen für eine Pushregel verfügen, die Personen, die über Umgehungsberechtigungen im Stamm-Repository verfügen.

Informationen zu Regelsätzen und geschützten Branches

Regelsätze funktionieren zusammen mit allen Branchschutzregeln in einem Repository. Viele der Regeln, die du in Regelsätzen definieren kannst, ähneln Schutzregeln, und du kannst mit der Verwendung von Regelsätzen beginnen, ohne deine vorhandenen Schutzregeln zu überschreiben.

Regelsätze haben gegenüber Branch- die folgenden Vorteile.

• Im Gegensatz zu Schutzregeln können mehrere Regelsätze gleichzeitig angewendet werden, sodass du sicher sein kannst, dass jede Regel, die auf einen Branch in deinem Repository abzielt, ausgewertet wird, wenn jemand mit diesem Branch oder Tag interagiert. Weitere Informationen findest du unter Informationen zur Regelschichtung.
• Regelsätze weisen Status auf, sodass du einfach verwalten kannst, welche Regelsätze in einem Repository aktiv sind, ohne dass Regelsätze gelöscht werden müssen.
• Alle Personen mit Lesezugriff auf ein Repository können die aktiven Regelsätze für das Repository anzeigen. Dies bedeutet, dass Entwicklerinnen verstehen können, warum sie eine Regel getroffen haben, oder Auditorinnen können die Sicherheitseinschränkungen für das Repository überprüfen, ohne dass sie Administratorzugriff auf das Repository benötigen.
• Sie können zusätzliche Regeln erstellen, um die Metadaten von Commits zu steuern, die in einem Repository eingehen, z. B. die Commitnachricht und die E-Mail-Adresse des Autors. Weitere Informationen findest du unter Verfügbare Regeln für Regelsätze.

Verwenden von Regelsatz-Erzwingungsstatus

Beim Erstellen oder Bearbeiten Ihres Regelsatzes können Sie Erzwingungsstatus verwenden, um zu konfigurieren, wie Ihr Regelsatz erzwungen wird.

Sie können einen der folgenden Erzwingungsstatus für Ihr Regelsatz auswählen.

• Active: Dein Regelsatz wird beim Erstellen erzwungen.
• Evaluate: Dein Regelsatz wird nicht erzwungen, doch du kannst überwachen auf der Seite „Rule Insights“ überwachen, welche Aktionen die Regeln verletzen würden.
• Disabled: Dein Regelsatz wird nicht erzwungen oder ausgewertet.

Die Verwendung des Modus „Auswerten“ ist eine hervorragende Option zum Testen des Regelsets, ohne es zu erzwingen. Sie können die Seite „Regeleinblicke“ verwenden, um festzustellen, ob der Beitrag gegen die Regel verstoßen hätte. Weitere Informationen findest du unter Verwalten von Regelsätzen für ein Repository.

Informationen zur Regelschichtung

Ein Regelsatz hat keine Priorität. Wenn mehrere Regelsätze auf denselben Branch oder dasselbe Tag in einem Repository abzielen, werden die Regeln stattdessen in jedem dieser Regelsätze aggregiert. Wenn dieselbe Regel in den aggregierten Regelsätzen auf unterschiedliche Weise definiert ist, gilt die restriktivste Version der Regel. Neben der Schichtung untereinander können Regelsätze auch mit Schutzregeln geschichtet werden, die auf denselben Branch oder dasselbe Tag ausgerichtet sind.

Betrachte beispielsweise die folgende Situation für den my-feature-Branch des octo-org/octo-repo-Repositorys.

• Eine Administratorin des Repositorys hat einen Regelsatz für den my-feature-Branch eingerichtet. Dieser Regelsatz erfordert signierte Commits und drei Reviews für Pull Requests, bevor sie gemergt werden können.
• Eine vorhandene Branchschutzregel für den my-feature-Branch erfordert einen linearen Commitverlauf und zwei Reviews für Pull Requests, bevor sie gemergt werden können.
• Eine Administratorin der Organisation octo-org hat auch einen Regelsatz für den my-feature-Branch des octo-repo-Repositorys eingerichtet. Der Regelsatz blockiert erzwungene Pushs und erfordert einen Review für Pull Requests, bevor sie gemergt werden können.

Die Regeln aus jeder Quelle werden aggregiert, und alle Regeln gelten. Wenn mehrere verschiedene Versionen derselben Regel vorhanden sind, gilt die restriktivste Version der Regel. Daher erfordert der my-feature-Branch signierte Commits und einen linearen Commitverlauf, erzwungene Pushs werden blockiert, und Pull Requests für den Branch erfordern drei Reviews, bevor sie gemergt werden können.