Personen mit Administrator- oder Inhaberberechtigungen können eine CODEOWNERS-Datei in einem Repository einrichten.
Die Personen, die du als Codeinhaber auswählst, müssen Schreibberechtigungen für das Repository haben. Wenn der Codebesitzer ein Team ist, muss das Team sichtbar sein und über Schreibberechtigungen verfügen. Dies gilt 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 zu Pull Requests-Entwürfen findest du unter Informationen zu Pull Requests. Code-Besitzer werden nicht automatisch aufgefordert, Entwürfe für Pull Requests zu überprüfen. Wenn du einen Pull Request in einen Entwurf konvertierst, werden Personen, die bereits Benachrichtigungen abonniert haben, nicht automatisch abgemeldet. Weitere Informationen findest du unter Die 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 Informationen zu geschützten Branches.
Wenn eine Datei einen Codebesitzerin hat, kannst du sehen, wer dies ist, bevor du einen Pull Request öffnest. Du kannst im Repository zur Datei navigieren und den Mauszeiger über bewegen.
Speicherort der CODEOWNERS-Datei
Um eine CODEOWNERS-Datei zu verwenden, erstellst du eine neue Datei namens CODEOWNERS im Stammverzeichnis oder im Verzeichnis docs/ oder .github/ des Repositorys in dem Branch, in dem du die Codebesitzer hinzufügen möchtest.
Jede CODEOWNERS-Datei ordnet die Codeinhaber für einen einzelnen Branch im Repository zu. So kannst du verschiedenen Codebesitzer für unterschiedliche Branches zuweisen, z. B. @octo-org/codeowners-team für eine Codebasis im Standardbranch und @octocat für eine GitHub Pages-Website im Branch gh-pages.
Damit Codeinhaber Review-Anfragen erhalten können, muss sich die CODEOWNERS-Datei auf dem Basis-Branch des Pull Requests befinden. Wenn du z. B. @octocat als Codebesitzer für .js-Dateien im Branch gh-pages deines Repositorys zuweist, erhält @octocat Überprüfungsanforderungen, wenn ein Pull Request mit Änderungen an .js-Dateien zwischen Headbranch und gh-pages erstellt wird.
Größe von CODEOWNERS-Dateien
CODEOWNERS-Dateien müssen kleiner als 3 MB sein. Eine CODEOWNERS-Datei über diesen Grenzwert wird nicht geladen. Das bedeutet, dass keine Informationen zum Codebesitzer angezeigt und die entsprechenden Codebesitzer nicht aufgefordert werden, Änderungen in einem Pull Request zu überprüfen.
Um die Größe deiner CODEOWNERS-Datei zu verringern, kannst du Platzhaltermustern verwenden, um mehrere Einträge in einem zusammenzufassen.
CODEOWNERS-Syntax
Warnung: Es gibt einige Syntaxregeln für GITIGNORE-Dateien, die in CODEOWNERS-Dateien nicht funktionieren:
- Auskommentieren eines Musters, das mit
#beginnt und\enthält, sodass es als Muster behandelt wird und nicht als Kommentar - Verwenden von
!zum Negieren eines Musters - Verwenden von
[ ]zum Definieren eines Zeichenbereichs
Eine CODEOWNERS-Datei verwendet ein Muster, das den meisten Regeln folgt, die auch für gitignore-Dateien gelten. Dem Muster folgen ein oder mehrere GitHub-Benutzernamen oder -Teamnamen im Standardformat @username oder @org/team-name. Benutzer*innen und Teams müssen expliziten write-Zugriff auf das Repository haben, auch wenn die Teammitglieder bereits Zugriff haben.
Wenn du zwei oder mehr Codebesitzerinnen mit demselben Muster abgleichen möchtest, müssen alle Codebesitzerinnen auf derselben Zeile stehen. Wenn sich die Codebesitzerinnen nicht auf derselben Zeile befinden, findet das Muster nur den/die zuletzt erwähnte Codebesitzerin.
Du kannst auch mithilfe einer E-Mail-Adresse auf Benutzer verweisen, die in deine GitHub Enterprise Server-Instanz deren Konto hinzugefügt wurde, z. B. user@example.com.
Bei CODEOWNERS-Pfaden wird die Groß- und Kleinschreibung berücksichtigt, da GitHub ein Dateisystem mit Beachtung von Groß- und Kleinschreibung verwendet. Da CODEOWNERS von GitHub ausgewertet werden, muss auch bei Systemen mit Beachtung der Groß- und Kleinschreibung (z. B. macOS) bei den Pfaden und Dateien die richtige Groß- und Kleinschreibung in der CODEOWNERS-Datei verwendet werden.
Wenn eine Zeile in deiner CODEOWNERS-Datei ungültige Syntax enthält, wird diese Zeile übersprungen. Wenn du zur CODEOWNERS-Datei in deinem Repository auf deine GitHub Enterprise Server-Instanz navigierst, werden Fehler hervorgehoben. Auf eine Liste der Fehler in der CODEOWNERS-Datei eines Repositorys kannst du über die API zugreifen. Weitere Informationen findest du in der REST-API-Dokumentation unter Repositorys.
Beispiel für eine CODEOWNERS-Datei
# This is a comment.
# Each line is a file pattern followed by one or more owners.
# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence,
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.
* @global-owner1 @global-owner2
# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only @js-owner and not the global
# owner(s) will be requested for a review.
*.js @js-owner #This is an inline comment.
# You can also use email addresses if you prefer. They'll be
# used to look up users just like we do for commit author
# emails.
*.go docs@example.com
# Teams can be specified as code owners as well. Teams should
# be identified in the format @org/team-name. Teams must have
# explicit write access to the repository. In this example,
# the octocats team in the octo-org organization owns all .txt files.
*.txt @octo-org/octocats
# In this example, @doctocat owns any files in the build/logs
# directory at the root of the repository and any of its
# subdirectories.
/build/logs/ @doctocat
# The `docs/*` pattern will match files like
# `docs/getting-started.md` but not further nested files like
# `docs/build-app/troubleshooting.md`.
docs/* docs@example.com
# In this example, @octocat owns any file in an apps directory
# anywhere in your repository.
apps/ @octocat
# In this example, @doctocat owns any file in the `/docs`
# directory in the root of your repository and any of its
# subdirectories.
/docs/ @doctocat
# In this example, any change inside the `/scripts` directory
# will require approval from @doctocat or @octocat.
/scripts/ @doctocat @octocat
# In this example, @octocat owns any file in a `/logs` directory such as
# `/build/logs`, `/scripts/logs`, and `/deeply/nested/logs`. Any changes
# in a `/logs` directory will require approval from @octocat.
**/logs @octocat
# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as its owners are left empty.
/apps/ @octocat
/apps/github
CODEOWNERS und Branchschutz
Repositorybesitzer können Branchschutzregeln hinzufügen, um sicherzustellen, dass geänderter Code von den Besitzer*innen der geänderten Dateien überprüft wird. Weitere Informationen findest du unter Informationen zu geschützten Branches.