Informationen zu Codeinhabern

Personen mit Administrator- oder Inhaberberechtigungen können eine CODEOWNERS-Datei in einem Repository einrichten.

Die Personen, die Du als Codeinhaber auswählst, müssen Schreibberechtigung für das Repository haben. Wenn der Codeinhaber ein Team ist, benötigt das Team Schreibberechtigung, auch wenn alle einzelnen Teammitglieder über die Organisations- oder eine andere Teammitgliedschaft bereits Schreibberechtigung besitzen.

Informationen zu Codeinhabern

Code-Besitzer werden automatisch zur Überprüfung aufgefordert, wenn jemand einen Pull Request öffnet, der den Code ändert, den sie besitzen. Code-Besitzer werden nicht automatisch aufgefordert, Entwürfe für Pull Requests zu überprüfen. Weitere Informationen über Pull-Request-Entwürfe findest Du unter "Über Pull Requests. Wenn Du einen Pull Request als bereit zum Review markierst, werden die Code-Besitzer automatisch benachrichtigt. Wenn Du einen Pull Request in einen Entwurf konvertierst, werden Personen, die bereits Benachrichtigungen abonniert haben, nicht automatisch abgemeldet. Weitere Informationen findest Du unter „Den Zustand eines Pull Requests ändern.“

Wenn ein Benutzer mit Administrator- oder Inhaberberechtigungen die erforderlichen Reviews aktiviert hat, kann er optional auch die Genehmigung von einem Codeinhaber anfordern, bevor der Autor einen Pull Request im Repository zusammenführen kann. Weitere Informationen findest Du unter „Erforderliche Reviews für Pull Requests aktivieren.“

Wenn ein Team die Zuweisung zur Code-Überprüfung aktiviert hat, werden die individuellen Genehmigungen alleine nicht die Anforderung für die Genehmigung des Codeinhabers in einem geschützten Zweig erfüllen. Weitere Informationen findest Du unter „Code Review-Zuweisung für Dein Team verwalten."

Wenn eine Datei einen Codeinhaber hat, kannst Du sehen, wer der Codeinhaber ist, bevor Du einen Pull Request öffnest. Im Repository kannst Du zur Datei navigieren und den Mauszeiger über bewegen.

Speicherort der CODEOWNERS-Datei

Um eine CODEOWNERS-Datei zu verwenden, erstelle eine neue Datei mit dem Namen CODEOWNERS im root-, docs/- oder .github/-Verzeichnis des Repositorys, in dem Branch, in dem Du die Codeinhaber hinzufügen möchtest.

Jede CODEOWNERS-Datei ordnet die Codeinhaber für einen einzelnen Branch im Repository zu. So kannst Du verschiedene Codeinhaber für verschiedene Branches zuweisen, beispielsweise @octo-org/codeowners-team für eine Codebasis auf dem master-Branch und @octocat für eine GitHub Pages-Website auf dem gh-pages-Branch.

Damit Codeinhaber Review-Anfragen erhalten können, muss sich die CODEOWNERS-Datei auf dem Basis-Branch des Pull Requests befinden. Wenn Du beispielsweise @octocat als Codeinhaber für .js-Dateien auf dem gh-pages-Branch Deines Repositorys festlegst, erhält @octocat Review-Anforderungen, wenn ein Pull Request mit Änderungen für die .js-Dateien zwischen dem Head-Branch und dem gh-pages-Branch geöffnet wird.

CODEOWNERS-Syntax

Eine CODEOWNERS-Datei verwendet ein Muster, das den gleichen Regeln folgt wie in gitignore-Dateien. Dem Muster folgen ein oder mehrere GitHub-Benutzernamen oder -Teamnamen im Standardformat @benutzername oder @org/teamname. Du kannst auf einen Benutzer auch über eine E-Mail-Adresse verweisen, die zu dessen GitHub-Konto hinzugefügt wurde, z. B. benutzer@beispiel.com.

Beispiel für eine CODEOWNERS-Datei

# Dies ist ein Kommentar.
# Jede Zeile ist ein Dateimuster, dem ein oder mehrere Inhaber folgen.

# Diese Inhaber sind die Standardinhaber für alles im
# Repository. Sofern keine spätere Entsprechung Vorrang hat,
# erhalten @global-owner1 und @global-owner2 eine
# Review-Anfrage, wenn jemand einen Pull Request öffnet.
*       @global-owner1 @global-owner2

# Die Reihenfolge ist wichtig; das letzte Entsprechungsmuster
# hat höchste Priorität. Wenn jemand einen Pull Request öffnet,
# der nur JS-Dateien ändert, erhält nur @js-owner und nicht
# der/die globale(n) Inhaber eine Review-Anfrage.
*.js    @js-owner

# Bei Bedarf kannst Du auch E-Mail-Adressen verwenden. Sie werden
# verwendet, um Benutzer nachzuschlagen, genau wie bei
# Commit-Autoren-E-Mails.
*.go docs@beispiel.com

# In diesem Beispiel ist @doctocat Inhaber aller Dateien im
# build/logs-Verzeichnis im Stammverzeichnis des Repositorys
# und in allen Unterverzeichnissen.
/build/logs/ @doctocat

# Das Muster `docs/*` entspricht Dateien wie
# `docs/getting-started.md`, aber nicht weiter verschachtelten
# Dateien wie `docs/build-app/troubleshooting.md`.
docs/*  docs@beispiel.com

# In diesem Beispiel ist @octocat Inhaber irgendeiner Datei
# in einem Apps-Verzeichnis irgendwo in Ihrem Repository.
apps/ @octocat

# In diesem Beispiel ist @doctocat Inhaber irgendeiner Datei
# im Verzeichnis `/docs` im Stammverzeichnis Ihres Repositorys.
/docs/ @doctocat

Weiterführende Informationen

• „Neue Dateien erstellen“
• „Mitarbeiter in ein persönliches Repository einladen“
• „Den Zugriff einer Person auf ein Repository einer Organisation verwalten“
• „Den Teamzugriff auf ein Repository einer Organisation verwalten“
• „Einen Pull-Request-Review anzeigen“