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.“
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 Enterprise-Konto hinzugefügt wurde, z. B. benutzer@beispiel.com.
If any line in your CODEOWNERS file contains invalid syntax, the file will not be detected and will not be used to request reviews. Invalid syntax includes inline comments and user or team names that do not exist on GitHub Enterprise.
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