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 Code-Eigentümern
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-Request-Entwürfen findest du unter Informationen zu Pull Requests. Wenn Sie einen Entwurf eines Pull-Requests als bereit zur Überprüfung markieren, werden 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 finden Sie unter Die Phase 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 finden Sie unter Informationen zu geschützten Branches.
Wenn eine Datei einen Codebesitzerin hat, kannst du sehen, wer dies ist, bevor du einen Pull Request öffnest. Im Repository können Sie zur Datei navigieren und den Mauszeiger auf bewegen, um eine QuickInfo mit Codeownership-Details 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 in mehr als einem dieser Speicherorte vorhanden sind, GitHub suchen Sie in dieser Reihenfolge nach ihnen, und verwenden Sie die erste, die sie findet.
Jede CODEOWNERS-Datei ordnet die Codeinhaber für einen einzelnen Branch im Repository zu. Daher können Sie unterschiedlichen Codeverantwortlichen verschiedene Branches zuweisen, z. B. @octo-org/codeowners-team für eine Codebasis im Standard-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 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 ein Branch innerhalb deines Forks ist, verwendet der Pull Request die CODEOWNERS-Datei aus diesem Branch in deinem Fork, löst jedoch nur Überprüfungsanforderungen aus, wenn die Code-Besitzer speziell mit write-Zugriff zu deinem Fork hinzugefügt werden.
Wenn Sie sehen möchten, wer für eine Datei verantwortlich ist, indem Sie mit der Maus auf zeigen, werden Ihnen Informationen aus der Datei CODEOWNERS für den jeweiligen Branch im jeweiligen Repository angezeigt, das Sie gerade betrachten.
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:
- 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. Auf das 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.
Hinweis
Bei der Verwendung von Teams können nur Organisationsteams Codebesitzer sein. Unternehmensteams werden nicht als Codebesitzer unterstützt. Siehe Teams in einem Unternehmen.
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, entspricht das Muster nur dem/der letzte genannten Codebesitzerin.
In den meisten Fällen können Sie einen Benutzer auch über eine E-Mail-Adresse ansprechen, die seinem Konto hinzugefügt wurde, zum Beispiel user@example.com.
Sie können keine E-Mail-Adresse verwenden, um auf ein verwaltetes Benutzerkonto zu verweisen. Weitere Informationen verwaltete Benutzerkontenfinden Sie in der Dokumentation unter .
Pfade in CODEOWNERS unterscheiden zwischen Groß- und Kleinschreibung, da GitHub ein Dateisystem verwendet, das zwischen Groß- und Kleinschreibung unterscheidet. Da CODEOWNERS von GitHub ausgewertet werden, müssen selbst auf Systemen, die nicht zwischen Groß- und Kleinschreibung unterscheiden (z. B. macOS), in der CODEOWNERS-Datei Pfade und Dateinamen mit korrekter Groß- und Kleinschreibung angegeben 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 finden Sie 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. Bearbeiten Sie die Branch-Schutzregel und aktivieren Sie die Option „Überprüfung durch Code-Eigentümer erforderlich“. Weitere Informationen finden Sie unter Informationen zu geschützten Branches.
Hinweis
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-owner1oder@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.
Als Alternative zu Verzweigungsschutzregeln können Sie Regelsätze erstellen. Rulesets haben einige Vorteile gegenüber Verzweigungsschutzregeln, z. B. Status, und eine bessere Auffindbarkeit, ohne dass ein Administratorzugriff erforderlich ist. Sie können auch mehrere Regelsätze gleichzeitig anwenden. Weitere Informationen finden Sie unter Informationen zu Regelsätzen.