Artikelversion: Enterprise Server 2.17
Informationen zu Codeinhabern
Sie können eine CODEINHABER-Datei verwenden, um Personen oder Teams zu definieren, die für den Code in einem Repository verantwortlich sind.
Definiere die Codeinhaber in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen, und in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team, GitHub Enterprise Cloud, und GitHub Enterprise Server.
Personen mit Administrator- oder Inhaberrechten können eine CODEINHABER-Datei in einem Repository einrichten.
Die Personen, die Sie als Codeinhaber auswählen, müssen über Schreibrechte für das Repository verfügen. Wenn der Codeinhaber ein Team ist, benötigt das Team Schreibrechte, auch wenn alle einzelnen Teammitglieder bereits Schreibrechte besitzen (über die Organisationsmitgliedschaft oder eine andere Teammitgliedschaft).
Informationen zu Codeinhabern
Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. Code owners are not automatically requested to review draft pull requests. For more information about draft pull requests, see "About pull requests." When you mark a draft pull request as ready for review, code owners are automatically notified. If you convert a pull request to a draft, people who are already subscribed to notifications are not automatically unsubscribed. For more information, see "Changing the stage of a pull request."
Wenn ein Benutzer mit Administrator- oder Inhaberrechten die erforderlichen Reviews aktiviert hat, kann er optional auch die Genehmigung von einem Codeinhaber anfordern, bevor der Autor einen Pull Request im Repository mergen kann. For more information, see "Enabling required reviews for pull requests."
Speicherort der CODEINHABER-Datei
Um eine CODEINHABER-Datei zu verwenden, erstellen Sie eine neue Datei mit dem Namen CODEOWNERS im Stammverzeichnis docs/ oder im Verzeichnis .github/ des Repositorys, in dem Branch, in dem Sie die Codeinhaber hinzufügen möchten.
Jede CODEINHABER-Datei ordnet die Codeinhaber für einen einzelnen Branch im Repository zu. So können Sie verschiedene Codeinhaber für verschiedene Branches zuweisen, beispielsweise @octo-org/codeowners-team für eine Codebasis auf dem Branch master und @octocat für eine GitHub Pages-Website auf dem Branch gh-pages.
Damit Codeinhaber Review-Anfragen erhalten können, muss sich die CODEINHABER-Datei auf dem Basis-Branch des Pull Requests befinden. Wenn Sie beispielsweise @octocat als Codeinhaber für .js-Dateien auf dem Branch gh-pages Ihres Repositorys festlegen, erhält @octocat Review-Anforderungen, wenn ein Pull Request mit Änderungen für die .js-Dateien zwischen dem Head-Branch und dem Branch gh-pages geöffnet wird.
CODEINHABER-Syntax
Eine CODEINHABER-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. Sie können auf einen Benutzer auch über eine E-Mail-Adresse verweisen, die zu dessen GitHub Enterprise-Konto hinzugefügt wurde, z. B. benutzer@beispiel.com.
Beispiel für eine CODEINHABER-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 können Sie 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