Hallo, Entdecker! An dieser Seite wird aktiv gearbeitet, oder sie wird noch übersetzt. Die neuesten und genauesten Informationen finden Sie in unserer englischsprachigen Dokumentation.

Diese Version von GitHub Enterprise wird eingestellt am Diese Version von GitHub Enterprise wurde eingestellt am 2020-01-22. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nehmen Sie ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wenden Sie sich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

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.

You can define code owners in public repositories with GitHub Free, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server.

Inhalt dieses Artikels

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

Codeinhaber werden automatisch zum Review aufgefordert, wenn jemand einen Pull Request öffnet, durch den der Code, den sie besitzen, geändert wird.

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. Weitere Informationen finden Sie unter „Erforderliche Reviews für Pull Requests aktivieren“.

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

Weiterführende Informationen

Menschliche Unterstützung einholen

Sie können das Gesuchte nicht finden?

Kontakt