Ein Repository ohne Regeln am Hauptzweig ist eine Einladung zum direkten Push auf main. Das geht lange gut, bis jemand versehentlich einen kaputten Commit reindrückt oder eine ungeprüfte Änderung in Produktion landet. GitHub bietet zwei Mechanismen, um das zu verhindern: die klassischen Branch Protection Rules und die neueren Rulesets. Beide sichern denselben Punkt ab, aber sie unterscheiden sich in Reichweite und Verwaltbarkeit.

Branch Protection Rules, der klassische Weg

Branch Protection Rules gibt es seit Jahren. Man legt pro Branch-Muster fest, was gelten soll: Pull Request vor dem Merge, eine Mindestzahl an Reviews, bestandene Status Checks, keine Force Pushes. Für ein einzelnes Repository mit einem geschützten main reicht das völlig aus. Die Grenze zeigt sich, sobald man dieselbe Regel über viele Repositories hinweg einheitlich halten will. Jede Protection Rule lebt in genau einem Repository, und es gibt keine saubere Vererbung von der Organisation nach unten.

Rulesets, der neue Ansatz

Rulesets lösen genau dieses Problem. Sie lassen sich auf Repository-Ebene oder auf Organisationsebene definieren und dann über Muster auf viele Repositories anwenden. Mehrere Rulesets können gleichzeitig greifen, und GitHub wertet sie additiv aus: Was ein Ruleset verlangt, kann ein anderes nicht wieder aufweichen. Dazu kommt ein Evaluationsmodus, in dem man eine Regel erst mitlaufen lässt und die Verstöße im Log sieht, bevor man sie scharf schaltet. Das nimmt viel Risiko aus einer Umstellung, weil man vorher sieht, wen die Regel treffen würde.

Ein Ruleset besteht aus drei Teilen: dem Ziel (welche Branches oder Tags), der Durchsetzungsstufe (aktiv, Evaluation oder deaktiviert) und den eigentlichen Regeln. Als JSON sieht ein minimales Beispiel so aus:

{
  "name": "protect-main",
  "target": "branch",
  "enforcement": "active",
  "conditions": {
    "ref_name": { "include": ["refs/heads/main"], "exclude": [] }
  },
  "rules": [
    { "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": false
      }
    },
    { "type": "required_status_checks",
      "parameters": {
        "required_status_checks": [
          { "context": "build" },
          { "context": "test" }
        ]
      }
    },
    { "type": "non_fast_forward" }
  ]
}

Die Regel non_fast_forward blockiert Force Pushes, pull_request erzwingt den Review-Weg, und required_status_checks bindet den Merge an grüne Pipelines. Dieses JSON lässt sich per API deployen, was den entscheidenden Vorteil gegenüber der klassischen Variante ausmacht: Die Regel liegt versioniert im Code und nicht nur als Klickzustand in der Weboberfläche.

Welche Regeln sich wirklich lohnen

Nicht jede verfügbare Option trägt gleich viel bei. Die folgenden vier bringen den größten Effekt bei geringstem Reibungsverlust:

• Pull Request erforderlich mit mindestens einem Review. Der Kern jeder Absicherung. Ohne diese Regel ist alles andere Kosmetik.
• Status Checks erforderlich. Der Merge wartet auf Build und Tests. So kommt kein roter Stand auf main.
• Stale Reviews verwerfen. Wird nach einem Approval noch gepusht, verfällt die Freigabe. Sonst reviewt man einen Stand, der nicht mehr gemergt wird.
• Force Push blockieren. Verhindert das Überschreiben der Historie am Hauptzweig, absichtlich oder aus Versehen.

Regeln wie erzwungene lineare Historie oder Signaturpflicht auf Commits sind sinnvoll, aber sie erhöhen die Einstiegshürde. Wer sie einführt, sollte den Evaluationsmodus nutzen und dem Team vorher sagen, was kommt.

Ein Detail, das oft übersehen wird

Standardmäßig gelten Rulesets auch für Administratoren nur, wenn man das explizit will. Über Bypass-Listen kann man einzelne Rollen oder Apps von einer Regel ausnehmen. Das ist praktisch für einen Break-Glass-Zugang, aber es ist auch die Stelle, an der eine gut gemeinte Regel leise ausgehöhlt wird. Wer eine Bypass-Liste pflegt, sollte regelmäßig prüfen, wer dort steht. Eine Schutzregel, die die halbe Organisation umgehen darf, schützt nichts.

Branch Protection und Rulesets sind kein Widerspruch. Rulesets sind der Weg nach vorn, besonders wenn man mehr als eine Handvoll Repositories betreut und die Regeln versioniert halten will. Für ein einzelnes Projekt tut es auch die klassische Protection Rule. Wichtiger als die Wahl des Mechanismus ist, dass am Ende überhaupt eine Regel greift und dass sie nicht durch eine zu großzügige Ausnahmeliste ins Leere läuft. Wie man solche Absicherungen in einen durchgängigen Lieferprozess einbettet, ist ein Thema für sich, dazu schreibe ich regelmäßig auf digital-business.blog.