Informationen zu Regelsätzen

Mit Regelsätzen kannst du steuern, wie Benutzer*innen mit Branches und Tags in einem Repository interagieren können.

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.

In diesem Artikel

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.

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.

Informationen zu Regelsätzen, geschützten Branches und geschützten Tags

Regelsätze funktionieren zusammen mit allen Branchschutzregeln und Tagschutzregeln 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.

Außerdem können Sie bestehende Schutzregeln für Tags in Repository-Regelsätze importieren. Dadurch werden dieselben Tag-Schutzfunktionen implementiert, die Sie derzeit für Ihr Repository eingerichtet haben. Weitere Informationen findest du unter Konfigurieren von Tagschutzregeln.

Regelsätze haben gegenüber Branch- und Tagschutzregeln 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 oder ein Tag in deinem Repository abzielt, ausgewertet wird, wenn jemand mit diesem Branch or tag 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 in der GitHub Enterprise Cloud-Dokumentation.

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.