Informationen zu Branches

Informationen zu Branches

Branches ermöglichen dir das Entwickeln von Features, Beheben von Fehlern und sichere Experimentieren mit neuen Ideen in einem Bereich deines Repositorys.

Du erstellst einen Branch immer aus einem existierenden Branch. Normalerweise würdest du einen neuen Branch aus dem Standardbranch deines Repositorys erstellen. Dann kannst du an diesem neuen Zweig unabhängig von Änderungen arbeiten, die von anderen Personen im Repository vorgenommen werden. Ein Branch, den Du zur Erstellung einer Funktion aufbaust, wird häufig als Funktions-Branch oder Themen-Branch bezeichnet. Weitere Informationen finden Sie unter AUTOTITLE.

Du kannst einen Zweig auch verwenden, um eine GitHub Pages-Website zu veröffentlichen. Weitere Informationen finden Sie unter AUTOTITLE.

Du benötigst Schreibzugriff auf ein Repository, um einen Branch zu erstellen, einen Pull Request zu öffnen oder Branches in einem Pull Request zu löschen und wiederherzustellen. Weitere Informationen finden Sie unter AUTOTITLE.

Informationen zum Standard-Branch

Wenn du ein Repository mit Inhalten auf GitHub erstellst, erstellt GitHub das Repository mit einem einzelnen Branch. Dieser erste Branch im Repository ist der Standardbranch. Der Standardbranch ist der Branch, den GitHub anzeigt, wenn eine Person dein Repository aufruft. Der Standardbranch ist auch der erste Branch, den Git lokal auscheckt, wenn jemand das Repository klont. Sofern du keinen anderen Branch angibst, ist der Standardbranch in einem Repository der Basisbranch für neue Pull Requests und Codecommits.

Der Standardbranch wird von in jedem neuen Repository standardmäßig genannt.

Du kannst den Standardbranch für ein vorhandenes Repository ändern. Weitere Informationen finden Sie unter Ändern des Standardbranchs.

Du kannst den Namen des Standardbranchs für neue Repositorys festlegen. Weitere Informationen findest du unter Verwalten des Standardbranchnamens für deine Repositorys, Verwalten des Standardbranchnamens für Repositorys in deiner Organisation und Richtlinien zur Verwaltung von Repositories in Ihrem Unternehmen erzwingen.

Mit Branches arbeiten

Wenn du mit deiner Arbeit zufrieden bist, kannst du einen Pull Request öffnen, um die Änderungen im aktuellen Branch (Headbranch) in einen anderen Branch (Basisbranch) zu mergen. Weitere Informationen finden Sie unter AUTOTITLE.

Nachdem ein Pull Request zusammengeführt oder geschlossen wurde, kannst Du den Head-Branch löschen, da dieser nicht mehr länger benötigt wird. Du benötigst Schreibzugriff auf dem Repository, um Branches zu löschen. Du kannst keine Branches löschen, die direkt mit einem offenen Pull Request verbunden sind. Weitere Informationen finden Sie unter AUTOTITLE.

Wenn du einen Haupt-Branch löschst, nachdem sein Pull Request zusammengeführt wurde, wird GitHub auf offene Pull Requests für das gleiche Repository prüfen, die den gelöschten Branch als ihren Basis-Branch angeben. GitHub aktualisiert solche Pull Requests automatisch, indem es deren Basis-Branch auf den Basis-Branch des zusammengeführten Pull Requests ändert. Die folgenden Diagramme veranschaulichen diesen Vorgang.

In diesem Fall hat jemand einen Branch namens aus dem -Branch erstellt, und du hast dann einen Branch namens aus erstellt. Es gibt für beide Branches offene Pull Requests. Der Pfeil zeigt den aktuellen Basis-Branch für jeden Pull Request an. Zu diesem Zeitpunkt ist der Basisbranch für . Wenn der Pull Request für jetzt gemergt wird, wird der -Branch in gemergt.

Im nächsten Diagramm hat jemand den Pull Request für in den -Branch gemergt und den -Branch gelöscht. Daher hat GitHub den Pull Request für automatisch umgeleitet, sodass dessen Basisbranch nun ist.

Wenn du nun den Pull Request mergst, wird er in den -Branch gemergt.

Mit geschützten Branches arbeiten

Repository-Administratoren oder benutzerdefinierte Rollen mit der Berechtigung „Repository-Regeln bearbeiten“ können Schutz für einen Zweig aktivieren. Wenn Du auf einem geschützten Branch arbeitest, kannst Du den Push an den Branch nicht löschen oder erzwingen. Repository-Administratoren können zusätzlich mehrere andere Einstellungen für geschützte Branches aktivieren, um verschiedene Workflows zu erzwingen, bevor ein Branch zusammengeführt werden kann.

Um zu ermitteln, ob dein Pull Request gemergt werden kann, wirf einen Blick in das Merge-Fenster am unteren Rand der Registerkarte Conversation des Pull Requests. Weitere Informationen findest du unter AUTOTITLE.

Wenn ein Branch geschützt ist, gelten bestimmte Regeln:

• Du kannst einen Push an den Branch nicht löschen oder erzwingen.
• Wenn die erforderlichen Statuschecks für den Branch aktiviert sind, kannst Du Änderungen erst dann in den Branch zusammenführen, wenn alle erforderlichen CI-Tests bestanden sind. Weitere Informationen finden Sie unter AUTOTITLE.
• Wenn erforderliche Pull-Request-Reviews auf dem Branch aktiviert sind, kannst du Änderungen in den Branch erst dann zusammenführen, wenn alle Anforderungen der Richtlinie für Pull-Request-Reviews erfüllt sind. Weitere Informationen finden Sie unter AUTOTITLE.
• Wenn die erforderliche Überprüfung durch einen Codeinhaber für einen Branch aktiviert ist und ein Pull Request Code ändert, der einen Inhaber hat, muss ein Codeinhaber den Pull Request freigeben, bevor er zusammengeführt werden kann. Weitere Informationen finden Sie unter AUTOTITLE.
• Wenn die obligatorische Commit-Signatur auf einem Branch aktiviert ist, kannst Du keine Commits an den Branch übertragen, die nicht signiert und verifiziert sind. Weitere Informationen finden Sie unter AUTOTITLE und AUTOTITLE.
• Wenn du den Konflikt-Editor von GitHub benutzt, um Konflikte für einen Pull Request zu beheben, den du aus einem geschützten Branch erstellt hast, hilft dir GitHub dabei, einen alternativen Branch für den Pull Request zu erstellen, sodass deine Auflösung der Konflikte gemergt werden kann. Weitere Informationen finden Sie unter AUTOTITLE.

Weiterführende Lektüre

• AUTOTITEL
• AUTOTITLE im Glossar von GitHub
• Zusammenfassung der Branches in der Git-Dokumentation