Skip to main content

Informationen zu Codeinhabern

Du kannst eine CODEOWNERS-Datei verwenden, um Personen oder Teams zu definieren, die für den Code in einem Repository verantwortlich sind.

Wer kann dieses Feature verwenden?

People with write permissions for the repository can create or edit the CODEOWNERS file and be listed as code owners. People with admin or owner permissions can require that pull requests have to be approved by code owners before they can be merged.

Du kannst Codebesitzer in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen sowie in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team, GitHub Enterprise Cloud und GitHub Enterprise Server definieren. Weitere Informationen findest du unter GitHub-Pläne.

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.

Screenshot: Kopfzeile einer Datei. Der Mauszeiger befindet sich über dem Schildsymbol, das die QuickInfo „Im Besitz von USER oder TEAM (aus der CODEOWNERS-Zeile NUMBER)“ anzeigt.

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

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.

In den meisten Fällen kannst du auch mithilfe einer E-Mail-Adresse auf Benutzer verweisen, die in GitHub.com 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 auf GitHub.com 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.

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

# 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.

Hinweis: Wenn Überprüfungen von Codebesitzer*innen 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 Verzweigungsschutzregeln oder den Tagschutz können Sie auch Regelsätze erstellen. Regelsätze haben einige Vorteile gegenüber Verzweigungs- und Tag-Schutzregeln, wie z. B. Status und bessere Auffindbarkeit, ohne dass ein Admin-Zugang erforderlich ist. Sie können auch mehrere Regelsätze gleichzeitig anwenden. Weitere Informationen findest du unter Informationen zu Regelsätzen.

Weiterführende Themen