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, um eine QuickInfo mit Details zum Codebesitz anzuzeigen.
Speicherort der CODEOWNERS-Datei
Um eine CODEOWNERS-Datei zu verwenden, erstellen Sie eine neue Datei namens CODEOWNERS im Stammverzeichnis oder im Verzeichnis .github/ oder docs/ des Repositorys in dem Branch, in dem Sie die Codebesitzer hinzufügen möchten. Wenn CODEOWNERS-Dateien an mehreren dieser Speicherorte vorhanden sind, werden sie von GitHub in dieser Reihenfolge gesucht, und die erste gefundene Datei wird verwendet.
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.
Codebesitzer und Verzweigungen
Um Überprüfungsanforderungen auszulösen, verwenden Pull Requests die Version CODEOWNERS des Basis-Branchs des Pull Requests. Der Basis-Branch ist die Verzweigung, die von einem Pull Request geändert wird, wenn der Pull Request zusammengeführt wird.
Wenn du einen Pull Request aus einer Verzweigung erstellst und sich der Basis-Branch im Upstream-Repository befindet, verwendet der Pull Request die CODEOWNERS Datei aus dieser Verzweigung im Upstream-Repository. Wenn der Basis-Branch eine Verzweigung in deiner Verzweigung ist, verwendet der Pull Request die CODEOWNERS Datei aus dieser Verzweigung in deiner Verzweigung, löst jedoch nur Überprüfungsanforderungen aus, wenn die Codebesitzer speziell mit write Zugriff zu deiner Verzweigung hinzugefügt werden.
Wenn du siehst, wer für eine Datei verantwortlich ist, indem du auf zeigst, werden Informationen aus der CODEOWNERS Datei für den Branch in dem Repository angezeigt, den du dir ansiehst.
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
Warning
Es gibt einige Syntaxregeln für GITIGNORE-Dateien, die in CODEOWNERS-Dateien nicht funktionieren:
- Das Maskieren eines Musters, das mit
#beginnt und\enthält, sodass es als Muster behandelt wird und nicht als Kommentar, funktioniert nicht. - Das Negieren eines Musters mit
!funktioniert nicht. - Das Definieren eines Zeichenbereichs mit
[ ]funktioniert nicht.
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.
In den meisten Fällen kannst du auf Benutzer mithilfe einer E-Mail-Adresse verweisen, die deren Konto hinzugefügt wurde, z. B. user@example.com. Du kannst nicht mit einer E-Mail-Adresse auf einen verwaltetes Benutzerkonto verweisen. Weitere Informationen zu verwaltete Benutzerkonten findest du unter Informationen zu Enterprise Managed Users.
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 Sie zu der CODEOWNERS-Datei in Ihrem Repository navigieren, werden alle Fehler hervorgehoben. Auf eine Liste der Fehler in der CODEOWNERS-Datei eines Repositorys kannst du über die API zugreifen. Weitere Informationen findest du unter REST-API-Endpunkte für Repositorys.
Wenn Sie einen Benutzer oder ein Team angeben, der/das nicht existiert oder keinen ausreichenden Zugriff hat, wird kein Codebesitzer zugewiesen.
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. Without an owner, changes
# to `apps/github` can be made with the approval of any user who has
# write access to the repository.
/apps/ @octocat
/apps/github
# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as this subdirectory has its own owner @doctocat
/apps/ @octocat
/apps/github @doctocat
CODEOWNERS und Branchschutz
Repositorybesitzer können Branch-schutzregeln aktualisieren, um sicherzustellen, dass geänderter Code von den Besitzer*innen der geänderten Dateien überprüft wird. Bearbeite die Branch-Schutzregel und aktiviere die Option „Überprüfung von Codebesitzern erforderlich“. Weitere Informationen findest du unter Informationen zu geschützten Branches.
Note
Wenn Überprüfungen von Codebesitzern erforderlich sind, reicht die Genehmigung eines Besitzers aus, um diese Anforderung zu erfüllen. Angenommen, Ihre CODEOWNERS-Datei enthält die folgende Zeile:
*.js @global-owner1 @global-owner2
Das bedeutet, dass Änderungen an JavaScript-Dateien entweder von @global-owner1 oder @global-owner2 genehmigt werden können, Genehmigungen von beiden jedoch nicht erforderlich sind.
Um ein Repository vollständig vor nicht autorisierten Änderungen zu schützen, musst du auch einen Besitzer für die CODEBESITZER-Datei definieren. Die sicherste Methode besteht darin, eine CODEBESIZER-Datei im .github Verzeichnis des Repositorys zu definieren und den Repositorybesitzer als Besitzer der CODEBESITZER-Datei (/.github/CODEOWNERS @owner_username) oder des gesamten Verzeichnisses (/.github/ @owner_username) zu definieren.
Alternativ zu den Regeln zum Schutz von Verzweigungen können Sie auch Regelsätze erstellen. Regelsätze haben einige Vorteile gegenüber branch Schutzregeln, wie z.B. Status und bessere Auffindbarkeit ohne Admin-Zugang. Sie können auch mehrere Regelsätze gleichzeitig anwenden. Weitere Informationen findest du unter Informationen zu Regelsätzen.