Zusammenfassung

  • CODEOWNERS ist eine nach Pfad und Branch wirkende Zuständigkeitskonfiguration; GitHub kann für einen Nicht-Entwurf-Pull-Request bei geändertem Owned Code automatisch Reviews anfordern.
  • Das Ergebnis hängt von der Basis-Branch-Datei, Ortspriorität, dem letzten passenden Muster, den geänderten Pfaden und gültigen Owner-Rechten ab. Eine heute sichtbare Datei belegt kein früheres Ergebnis.
  • Ein belastbarer Nachweis trennt anwendbare Konfiguration, Diff, Anfrage, Review-Antwort und weitere Merge-Bedingungen, statt sie zu einer Behauptung zu verdichten.

Eine Regel beschreibt den Weg, nicht seine Ausführung

„Die Eigentümer haben es geprüft“ klingt vollständig, lässt aber Entscheidendes offen. Welche Basis-Branch galt? Welche Dateien lagen im Diff? Welches Muster hatte Vorrang? Waren die genannten Nutzer oder Teams zu diesem Zeitpunkt berechtigt? Ging eine Anfrage hinaus und deckte eine Antwort genau diesen Stand ab? Das Anzeigen einer Datei beantwortet diese Kette nicht.

GitHub beschreibt CODEOWNERS als Mittel, Personen oder Teams als verantwortlich für Code eines Repositorys festzulegen. Ändert ein Nicht-Entwurf-Pull-Request besessenen Code, fordert GitHub bei den zutreffenden Ownern automatisch eine Review an. Entwürfe erzeugen diese Anfrage erst, wenn sie als reviewbereit markiert sind. Damit wird fachliche Aufmerksamkeit geroutet; eine Nachricht wird nicht zu einer erledigten Prüfung erklärt.

Der Branch gehört zur Regel. Jede CODEOWNERS-Datei ordnet Owner einem einzelnen Branch zu, und Review-Anfragen nutzen die Version auf dem Basis-Branch des Pull Requests. Kommt ein Beitrag aus einem Fork zum Upstream, gilt die Datei auf dessen Basis-Branch. Derselbe Patch kann für main und einen Wartungs-Branch somit andere Owner haben. Weder eine Datei im Head-Branch noch eine später im Standard-Branch sichtbare Version ist automatisch der Beleg für die damalige Zuordnung.

Auch der Ort ist Teil der Semantik. GitHub durchsucht .github/, dann das Wurzelverzeichnis, dann docs/ und nutzt die erste gefundene Datei. Eine Datei über drei Megabyte wird nicht geladen; dann werden weder Owner angezeigt noch passende Reviews angefordert. Ein Policy-Text kann im Repository liegen, ohne die fragliche Routing-Entscheidung getragen zu haben.

Das letzte Muster kann die Zuständigkeit verschieben

Muster wirken leicht additiv. Tatsächlich hat bei GitHub das zuletzt passende Muster Vorrang. Eine allgemeine *-Regel kann für eine JavaScript-Änderung durch ein späteres *.js ersetzt werden. Mehrere Owner auf einer Zeile teilen ein Muster; auf mehreren passenden Zeilen kann allein die spätere Zuordnung gelten. Wer nur die allgemeine Zeile zitiert, ohne Reihenfolge und Pfade zu rekonstruieren, kann eine Review einer Person zuschreiben, die nie angefragt wurde.

Hinzu kommen Gültigkeitsbedingungen. Pfade sind groß-/kleinschreibungssensitiv. Ungültige Zeilen werden übersprungen. Nicht existente oder unzureichend berechtigte Nutzer und Teams werden nicht als Owner zugeteilt. Das ist kein Vorwurf an ein bestimmtes Repository. Es zeigt nur, dass eine Konfigurationsansicht kein automatischer Nachweis eines Ereignisses ist.

GitHub empfiehlt zudem, die CODEOWNERS-Datei selbst einem Owner zuzuweisen. Die Empfehlung legt die Governance-Frage offen: Eine Regel, die Verantwortung verteilt, braucht einen sichtbaren eigenen Änderungsweg. Sonst ist klar, wer den Anwendungscode besitzen soll, nicht aber, wer die Besitzregel ändern konnte.

Review und Merge sind verschiedene Nachweise

GitHub trennt die automatische Review-Anfrage von der optionalen Einstellung, vor dem Merge eine Code-Owner-Genehmigung zu verlangen. Diese Anforderung wird getrennt konfiguriert. Bei mehreren Ownern eines Musters kann eine Zustimmung eines einzelnen genügen. Die Datei macht ihre Namen nicht von selbst zu verpflichtenden Merge-Sperren.

Daneben können Rulesets und Branch Protection zusammen gelten. Anwendbare Regeln werden aggregiert; bei unterschiedlichen Varianten derselben Regel gilt die restriktivere. Pull Request, Anzahl von Approvals, Code-Owner-Review, Status Checks, erfolgreiche Deployments, aufgelöste Kommentare, Merge-Methode und Bypass-Berechtigungen können getrennte Bedingungen sein. GitHub weist darauf hin, dass ein Pull Request trotz aller erforderlichen Approvals blockiert bleiben kann, wenn ein weiterer offener Pull Request auf demselben Head Commit eine ausstehende oder abgelehnte Review hat.

Ein Approval bleibt bedeutsam: Es signalisiert, dass Änderungen mergebereit erscheinen. Es ist jedoch ein Review-Status für einen abgegrenzten Diff, keine Gesamtquittung für jede Regel und jedes Folgeereignis.

Einen Konfiguration-zu-Review-Nachweis bewahren

Für eine folgenreiche Behauptung sollte der Nachweis mit Pull-Request-ID, Basis- und Head-Commit oder Tree sowie den geänderten Pfaden beginnen. Danach folgen Ort und Inhaltsidentität der auf dem Basis-Branch geltenden CODEOWNERS-Datei, das siegreiche Muster und die aufgelöste Owner-Menge. Erst dann kommen Ereignisse: Anfrage, Antwort, Zeitpunkt und abgedeckter Diff oder Commit.

Reicht eine Aussage bis zur Merge-Bereitschaft, müssen geltende Rulesets oder Schutzregeln, die beobachteten Zustände ihrer Bedingungen und jeder dokumentierte Bypass getrennt genannt werden. Fehlt ein Beleg, endet die Aussage beim letzten belegten Übergang. Das ist keine neue GitHub-Pflicht, sondern eine redaktionelle Grenze gegen die Verwechslung heutiger Konfiguration mit vollständiger vergangener Geschichte.

Quellen

  1. GitHub Docs — About code owners
  2. GitHub Docs — Pull request reviews
  3. GitHub Docs — About rulesets
  4. GitHub Docs — Available rules for rulesets