Warum `main` heilig ist

„Main ist immer grün" bedeutet eines: Zu jedem Zeitpunkt ist der main-Branch in die Produktion deploybar. Nicht „funktioniert meistens", nicht „funktioniert, wenn man weiß, welche Commits man überspringen muss" — deploybar. Genau jetzt. Ohne manuellen Eingriff.

Das ist eine höhere Messlatte, als den meisten Teams bewusst ist. Es bedeutet, dass jeder Commit auf main automatisierte Tests bestanden hat, von einem Menschen überprüft wurde und nicht von unvollständiger Arbeit aus einem anderen Branch abhängt. Es bedeutet, dass man am Freitag um 16 Uhr ohne Angst deployen kann, weil main keine laufende Arbeit ist — sondern das fertige Produkt bei jedem Commit.

Der Mechanismus, der dies durchsetzt, ist Continuous Integration (CI). Jeder PR führt die Test-Suite, den Linter und den Type-Checker aus, bevor er gemergt werden kann. Wenn eine Prüfung fehlschlägt, wird der PR blockiert. Der Entwickler behebt das Problem auf seinem Branch — nicht auf main, nicht nach dem Merge, nicht „später". CI ist der Türsteher, der sicherstellt, dass main niemals degradiert.

Teams ohne diese Disziplin befinden sich regelmäßig in einem Zustand, in dem main kaputt ist und niemand weiß, welcher der letzten fünf Merges die Ursache war. An diesem Punkt ist das gesamte Team blockiert — sie können keinen frischen Code pullen, keine neuen Branches von einem funktionierenden Zustand aus starten und nicht deployen. Die Kosten eines roten main sind nicht das Problem eines einzelnen Entwicklers. Es ist das Problem des gesamten Teams, das sich mit jeder Minute verschärft, in der es kaputt bleibt.

Branch-Protection-Regeln sind die automatisierte Durchsetzung von „Main ist immer grün". Jede große Git-Hosting-Plattform — GitHub, GitLab, Bitbucket — unterstützt sie, und sie sollten am ersten Tag jedes ernsthaften Projekts konfiguriert werden.

Die drei wichtigsten Regeln:

• Erforderliche PR-Reviews. Keine direkten Pushes auf main. Jede Änderung durchläuft einen PR und mindestens eine Freigabe. Dies fängt den „Ich pushe nur schnell diesen Fix"-Impuls ab, der für einen unverhältnismäßig großen Anteil an Produktionsvorfällen verantwortlich ist.
• Erforderliche Status-Checks. CI muss bestanden werden, bevor gemergt wird. Tests, Linting, Type-Checking — was auch immer Ihre Pipeline ausführt. Ein fehlgeschlagener Check blockiert den Merge-Button. Keine Overrides, kein „Ich behebe es im nächsten Commit".
• Lineare Historie. Verlangen Sie, dass Branches vor dem Merge mit main aktuell sind (Rebase oder Merge-Queue). Dies verhindert die Situation, in der zwei PRs jeweils einzeln CI bestehen, aber beim Zusammenführen brechen — weil jeder PR gegen den aktuellen Zustand von main getestet wird, nicht gegen einen veralteten Snapshot.

Einige Teams wehren sich gegen Protection-Regeln, weil sie sich wie Reibung anfühlen. Sie sind Reibung — absichtliche Reibung, die die teuerste Klasse von Fehlern verhindert. Diese Regeln zu konfigurieren dauert fünf Minuten. Sich von einem Force-Push zu erholen, der die Arbeit eines Teamkollegen überschreibt, dauert Stunden, plus den Vertrauensschaden. Die Rechnung ist eindeutig.

Wenn ein Deploy die Produktion kaputt macht, stehen Entwickler vor einer Wahl: vorwärts fixen oder reverten. Der Instinkt ist fast immer, vorwärts zu fixen — den Bug finden, einen Patch schreiben, pushen. Aber dieser Instinkt ist unter Druck falsch.

Ein Revert ist ein einzelner Befehl, der einen bekannten Commit sauber rückgängig macht:

git revert abc123f
# Creates a new commit that undoes abc123f
# Main is green again in minutes

Die Panik-Fix-Alternative sieht so aus: ein Entwickler, der um 23 Uhr über seiner Tastatur hockt, neuen Code unter Druck schreibt, Tests überspringt, weil „es nur ein einzeiliger Fix ist", direkt auf main pusht, weil „wir keine Zeit für einen PR haben". Dieser einzeilige Fix führt in 40 % der Fälle zu einem zweiten Bug, weil Code, der unter Adrenalin geschrieben wird, Code ohne vollständigen Kontext ist.

Die Regel ist einfach: Erst reverten, später fixen. Main sofort wieder auf grün bringen — das entblockt das gesamte Team und stoppt die Blutung. Dann, ohne Druck, einen ordentlichen Fix auf einem Branch mit Tests, Review und CI schreiben. Der Fix wird eine Stunde oder einen Tag später ausgeliefert, aber er wird korrekt ausgeliefert.

Reverts fühlen sich an wie das Eingeständnis eines Scheiterns. Sind sie nicht. Sie sind der schnellste Weg zurück zu einem funktionierenden Zustand, und sie hinterlassen den ursprünglichen Commit in der Historie als Dokumentation dessen, was schiefgelaufen ist. Ein Team, das schnell revertet, ist ein Team, das selbstbewusst ausliefert, weil die Kosten eines schlechten Deploys Minuten Ausfallzeit sind statt Stunden Feuerlöschen.