Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Informationen zu geschützten Branches

Du kannst wichtige Branches schützen, indem du Regeln für den Schutz von Branches festlegst. Diese definieren, ob Projektmitarbeiter*innen den Branchs löschen oder Pushes an ihn erzwingen können. Auch werden die Anforderungen für Pushes an den Branch festgelegt, z. B. das Bestehen von Statusüberprüfungen oder einen linearen Commitverlauf.

geschützte Zweige sind in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen und in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team, GitHub Enterprise Cloud, und GitHub Enterprise Server.

Informationen zu Branchschutzregeln

Durch das Erstellen von Branchschutzregeln kannst du bestimmte Workflows oder Anforderungen erzwingen, bevor eine Projektmitarbeiterin Änderungen an einen Branch in deinem Repository pushen kann (einschließlich des Mergens eines Pull Requests in den Branch).

Standardmäßig deaktiviert jede Branchschutzregel erzwungene Pushes an die übereinstimmenden Branches und verhindert, dass die übereinstimmenden Branches gelöscht werden. Du kannst diese Einschränkungen optional deaktivieren und zusätzliche Branchschutzeinstellungen aktivieren.

Standardmäßig gelten die Einschränkungen einer Branchschutzregel nicht für Personen mit Administratorrechten für das Repository oder für benutzerdefinierte Rollen mit der Berechtigung zum Umgehen des Branchschutzes. Optional kannst du die Einschränkungen auch auf Administratoren und Rollen mit der Berechtigung zum Umgehen des Branchschutzes anwenden. Weitere Informationen findest du unter Verwalten benutzerdefinierter Repositoryrollen für eine Organisation.

Du kannst eine Branchschutzregel in einem Repository für einen bestimmten Branch, für alle Branches oder für solche Branches erstellen, die mit einem Namensmuster übereinstimmen, das du mithilfe der fnmatch-Syntax angibst. Um beispielsweise alle Branches zu schützen, die das Wort release enthalten, kannst du eine Branchregel für *release* erstellen. Weitere Informationen zu Branchnamenmustern findest du unter Verwalten einer Branchschutzregel.

Du kannst einen Pull Request konfigurieren, um automatisch zusammenzuführen, wenn alle Zusammenführungsanforderungen erfüllt sind. Weitere Informationen findest du unter Automatisches Zusammenführen eines Pull Requests.

Informationen zu Branchschutzeinstellungen

Für jede Branchschutzregel kannst du die folgenden Einstellungen aktivieren oder deaktivieren.

Weitere Informationen zum Einrichten des Branchschutzes findest du unter Verwalten einer Branchschutzregel.

Erfordern von Pull-Request-Reviews vor dem Mergen

Repositoryadministratoren können erfordern, dass alle Pull Requests eine bestimmte Anzahl von Bewertungen erhalten, bevor jemand den Pull Request in einen geschützten Branch zusammenführt. Du kannst die Genehmigung von Bewertungen von Personen mit Schreibberechtigungen im Repository oder von einem bestimmten Codebesitzer anfordern.

Wenn du erforderliche Reviews aktivierst, können Projektmitarbeiterinnen Änderungen nur an einen geschützten Branch über einen Pull Request pushen, der von der erforderlichen Anzahl von Reviewerinnen mit Schreibberechtigungen genehmigt wurde.

Wenn eine Person mit Administratorberechtigungen bei einem Review auf die Option Änderungen anfordern klickt, muss diese Person den Pull Request genehmigen, bevor der Pull Request gemergt werden kann. Wenn Reviewerinnen, die Änderungen an einem Pull Request anfordern, der nicht verfügbar ist, können alle Benutzerinnen mit Schreibberechtigungen für das Repository den blockierenden Review verwerfen.

Selbst nachdem alle erforderlichen Reviewer einen Pull Request genehmigt haben, können Mitarbeiter den Pull Request nicht mergen, wenn andere offene Pull Requests mit einem HEAD-Branch vorhanden sind, der auf denselben Commit mit ausstehenden oder abgelehnten Reviews verweist. Zuerst muss eine Person mit Schreibberechtigungen den blockierenden Review für den anderen Pull Request genehmigen oder schließen.

Wenn eine Projektmitarbeiterin versucht, einen Pull Request mit ausstehenden oder abgelehnten Reviews in den geschützten Branch zu mergen, wird eine Fehlermeldung ausgegeben.

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

Optional kannst du veraltete Pull-Request-Genehmigungen verwerfen, wenn Commits gepusht werden. Wenn jemand einen Commit pusht, der Code in einen genehmigten Pull Request ändert, wird die Genehmigung verworfen, und der Pull Request kann nicht gemergt werden. Dies gilt nicht, wenn Projektmitarbeiter*innen Commits pushen, die keinen Code ändern (z. B. Mergen des Basisbranchs in den Branch des Pull Requests). Weitere Informationen zum Basisbranch findest du unter Informationen zu Pull Requests.

Optional kannst du die Berechtigung zum Verwerfen von Pull-Request-Reviews für bestimmte Personen oder Teams einschränken. Weitere Informationen findest du unter Verwerfen eines Pull-Request-Reviews.

Optional kannst du Reviews von Codebesitzerinnen anfordern. In diesem Fall muss jeder Pull Request, der sich auf Code mit Codebesitzerinnen auswirkt, von diesen Codebesitzer*innen genehmigt werden, bevor der Pull Request in den geschützten Branch gemergt werden kann.

Erfordern von Statusüberprüfungen vor dem Mergen

Mithilfe von erforderlichen Statuschecks wird sichergestellt, dass alle erforderlichen CI-Tests bestanden werden, bevor Mitarbeiter Änderungen an einem geschützten Branch vornehmen können. Weitere Informationen findest du unter „Geschützte Branches konfigurieren“ und „Erforderliche Statuschecks aktivieren“. Weitere Informationen findest du unter Informationen zu Statusüberprüfungen.

Bevor du die erforderlichen Statusüberprüfungen aktivieren kannst, musst du das Repository für die Verwendung der Commitstatus-API konfigurieren. Weitere Informationen findest du unter Commitstatuswerte in der REST-API-Dokumentation.

Nach der Aktivierung erforderlicher Statusüberprüfungen müssen alle erforderlichen Statusüberprüfungen durchlaufen werden, bevor Projektmitarbeiter*innen Änderungen in den geschützten Branch mergen können. Nachdem alle erforderlichen Statuschecks durchlaufen sind, müssen alle Commits entweder in einen anderen Branch übertragen und dann zusammengeführt oder direkt in den geschützten Branch übertragen werden.

Jede Person oder Integration mit Schreibberechtigungen für ein Repository kann den Status einer Statusüberprüfung im Repository festlegen, aber in manchen Fällen möchtest du vielleicht nur eine Statusüberprüfung von einer bestimmten GitHub App akzeptieren. Wenn du eine erforderliche Statusüberprüfung hinzufügst, kannst du eine App auswählen, die diese Überprüfung kürzlich als erwartete Quelle von Statusupdates festgelegt hat. Wenn der Status von einer anderen Person oder Integration festgelegt wird, ist das Mergen nicht zulässig. Wenn du „Beliebige Quelle“ auswählst, kannst du die Autor*innen jedes Status weiterhin manuell überprüfen (im Mergefeld aufgeführt).

Du kannst die erforderlichen Statusprüfungen entweder als "loose" (locker) oder als "strict" (streng) einrichten. Die Art der erforderlichen Statuschecks bestimmt, ob dein Branch vor dem Zusammenführen auf dem aktuellen Stand mit dem Basisbranch sein muss.

Art des erforderlichen StatuschecksEinstellungMerge-AnforderungenÜberlegungen
StrictDas Kontrollkästchen Aktualität von Branches vor dem Mergen erfordern ist aktiviert.Der Branch muss vor dem Mergen auf dem Stand des Basisbranchs sein.Dies ist das Standardverhalten für erforderliche Statuschecks. Weitere Builds können erforderlich sein, da du den Head-Branch auf den neuesten Stand bringen musst, nachdem andere Mitarbeiter Pull Requests in den geschützten Basisbranch überführt haben.
LockerDas Kontrollkästchen Aktualität von Branches vor dem Mergen erfordern ist nicht aktiviert.Der Branch muss vor dem Mergen nicht auf dem Stand des Basisbranchs sein.Es sind weniger Builds erforderlich, da du den Head-Branch nicht auf den neuesten Stand bringen musst, nachdem andere Mitarbeiter Pull Requests überführt haben. Statuschecks schlagen nach dem Zusammenführen deines Branches möglicherweise fehl, wenn inkompatible Änderungen am Basisbranch vorliegen.
DisabledDas Kontrollkästchen Durchlaufen von Statusüberprüfungen vor dem Mergen erfordern ist nicht aktiviert.Für den Branch gelten keine Merge-Einschränkungen.Wenn die erforderlichen Statuschecks nicht aktiviert sind, können Mitarbeiter den Branch unabhängig von seinem Stand gegenüber dem Basisbranch jederzeit zusammenführen. Die Wahrscheinlich inkompatibler Änderungen erhöht sich dadurch jedoch.

Informationen zur Problembehandlung findest du unter Problembehandlung bei erforderlichen Statusüberprüfungen.

Erfordern der Klärung von Konversationen vor dem Mergen

Alle Kommentare zum Pull Request müssen geklärt sein, bevor dieser in einen geschützten Branch gemergt werden kann. Auf diese Weise wird sichergestellt, dass vor dem Mergen alle Kommentare geklärt oder berücksichtigt wurden.

Erfordern signierter Commits

Wenn du die erforderliche Commitsignierung für einen Branch aktivierst, können Mitwirkende nur Commits pushen, die für den Branch signiert und verifiziert wurden. Weitere Informationen findest du unter Informationen zur Commitsignaturverifizierung.

Hinweis: Wenn eine Projektmitarbeiterin einen nicht signierten Commit an einen Branch pusht, der Commitsignaturen erfordert, muss ein Rebase für den Commit ausgeführt werden, damit eine verifizierte Signatur eingebunden und dann ein Push des neu geschriebenen Commits in den Branch erzwungen wird.

Du kannst jederzeit lokale Commits zum Branch übertragen, wenn die Commits signiert und verifiziert sind. Du kannst jedoch keine Pull Requests in den Branch auf GitHub Enterprise Server mergen. Du kannst Pull Requests lokal mergen. Weitere Informationen findest du unter Lokales Auschecken von Pull Requests.

Erfordern eines linearen Verlaufs

Durch das Erzwingen eines linearen Commitverlaufs wird verhindert, dass Projektmitarbeiter*innen Mergecommits an den Branch pushen. Dies bedeutet, dass alle Pull Requests, die in den geschützten Branch zusammengeführt sind, einen Squash-Merge oder einen Rebase-Merge verwenden müssen. Ein streng linearer Commitverlauf kann Teams dabei helfen, Änderungen einfacher rückgängig zu machen. Weitere Informationen zu Mergemethoden findest du unter Informationen zu Pull-Request-Merges.

Bevor du einen linearen Commit-Verlauf verlangen kannst, muss dein Repository Squash-Merge oder Rebase-Merge erlauben. Weitere Informationen findest du unter Konfigurieren von Pull-Request-Merges.

Erfordern erfolgreicher Bereitstellungen vor dem Mergen

Du kannst festlegen, dass Änderungen erfolgreich in bestimmten Umgebungen bereitgestellt werden müssen, bevor ein Branch gemergt werden kann. Du kannst diese Regel beispielsweise verwenden, um sicherzustellen, dass Änderungen erfolgreich in einer Stagingumgebung bereitgestellt werden, bevor die Änderungen in deinen Standardbranch gemergt werden.

Umgehung der oben genannten Einstellungen nicht zulassen

Standardmäßig gelten die Einschränkungen einer Branchschutzregel nicht für Personen mit Administratorrechten für das Repository oder für benutzerdefinierte Rollen mit der Berechtigung zum Umgehen des Branchschutzes in einem Repository.

Du kannst diese Einstellung aktivieren, um die Einschränkungen auch auf Administratoren und Rollen mit der Berechtigung zum Umgehen des Branchschutzes anzuwenden. Weitere Informationen findest du unter Verwalten benutzerdefinierter Repositoryrollen für eine Organisation.

Einschränken der Berechtigungen zum Pushen an übereinstimmende Branches

Wenn du Brancheinschränkungen aktivierst, können nur Benutzerinnen, Teams oder Apps mit den erforderlichen Berechtigungen an den geschützten Branch pushen. Du kannst die Benutzerinnen, Teams oder Apps mit Pushzugriff auf einen geschützten Branch in den Einstellungen für den geschützten Branch anzeigen und bearbeiten. Wenn Statusüberprüfungen erforderlich sind, werden die Personen, Teams und Apps, die die Berechtigung haben, in einen geschützten Branch zu pushen, trotzdem am Mergen in diesen Branch gehindert, wenn die erforderlichen Überprüfungen fehlschlagen. Personen, Teams und Apps, die über die Berechtigung zum Pushen an einen geschützten Branch verfügen, müssen weiterhin einen Pull Request erstellen, wenn Pull Requests erforderlich sind.

Optional kannst du die gleichen Einschränkungen auch auf die Erstellung von Branches anwenden, die der Regel entsprechen. Wenn du z. B. eine Regel erstellst, die es nur einem bestimmten Team erlaubt, in Branches zu pushen, die das Wort release enthalten, können nur Mitglieder dieses Teams einen neuen Branch erstellen, der das Wort release enthält.

Du kannst nur Benutzern, Teams oder installierten GitHub Apps mit Schreibzugriff auf ein Repository den Pushzugriff auf einen geschützten Branch oder die Berechtigung zum Erstellen eines entsprechenden Branches erteilen. Personen und Apps mit Administratorberechtigungen in einem Repository können immer Pushs in einen geschützten Branch ausführen oder einen entsprechenden Branch erstellen.

Erlauben erzwungener Pushes

Erzwungene Pushes werden von GitHub Enterprise Server standardmäßig für alle geschützten Branches blockiert. Wenn du erzwungene Pushes an einen geschützten Branch aktivierst, kannst du eine von zwei Gruppen auswählen, die Pushes erzwingen können:

  1. Jedem, der mindestens über Schreibberechtigungen für das Repository verfügt, das erzwungene Pushen an den Branch erlauben (einschließlich Benutzer*innen mit Administratorberechtigungen)
  2. Nur bestimmten Personen oder Teams das erzwungene Pushen an den Branch erlauben

Wenn jemand einen Push an einen Branch erzwingt, überschreibt der erzwungene Push möglicherweise Commits, auf denen die Arbeit anderer Projektmitarbeiterinnen basiert. Bei Benutzerinnen können Mergekonflikte oder beschädigte Pull Requests auftreten.

Das Aktivieren erzwungener Pushes wird keine anderen Branch-Schutzregeln überschreiben. Wenn ein Branch beispielsweise einen linearen Commit-Verlauf verlangt, kannst du keine Merge-Commit-Pushes zu diesem Branch erzwingen.

Du kannst erzwungene Pushes für einen geschützten Branch nicht aktivieren, wenn Websiteadministrator*innen erzwungene Pushes an alle Branches in deinem Repository blockiert haben. Weitere Informationen findest du unter Blockieren erzwungener Pushes in Repositorys im Besitz eines persönlichen Kontos oder einer Organisation.

Wenn ein Websiteadministrator erzwungene Pushes nur auf den Standardbranch blockiert hat, kannst du erzwungene Pushes trotzdem für jeden anderen geschützten Branch aktivieren.

Zulassen von Löschvorgängen

Standardmäßig kannst du einen geschützten Branch nicht löschen. Wenn du das Löschen eines geschützten Branchs aktivierst, können alle Benutzer*innen den Branch löschen, die mindestens über Schreibberechtigungen für das Repository verfügen.