Main und Master Branch in Git: Was es ist und warum man einen Hauptzweig braucht

Was ist Main / Master Branch in Git

Main Branch (oder Master – je nach Repository-Einstellungen) ist der Standardzweig, der beim Initialisieren eines beliebigen Git-Repositorys erstellt wird. Es ist der Hauptzweig des Projekts und enthält Code, der für die Produktionsbereitstellung bereit ist.

Im Gegensatz zu develop, wo die tägliche Arbeit mit neuen Funktionen in vollem Gange ist, ist main die Schaufenster des Projekts. Jede Codeversion in main hat einen vollständigen Zyklus durchlaufen: Entwicklung in einem Feature-Zweig, Integration in develop, Release-Vorbereitung in einem Release-Zweig und abschließende Tests. Erst danach gelangen Änderungen zu main.

Schlüsselprinzip: main muss immer stabil sein. Wenn ein Fehler in main gefunden wird, bedeutet dies, dass ein dringender Hotfix außer der Reihe veröffentlicht werden muss. Daher wird main in professionellen Projekten durch Branch-Schutzregeln vor versehentlichen Änderungen geschützt.

Laut Git Book ist main kein spezieller Zweig mit einzigartigen Eigenschaften, sondern ein normaler Verweis auf einen Commit, der konventionell als Hauptzweig betrachtet wird. Git unterscheidet auf Systemebene nicht zwischen main und einem anderen Zweig.

Übergang von master zu main

Historisch gesehen hieß der Standardzweig in Git master. Im Juni 2020 lenkte die Black-Lives-Matter-Bewegung die Aufmerksamkeit auf die Begriffe master und slave in der IT-Branche. GitHub kündigte den Übergang zum Begriff main für den Standardzweig an.

Seit Oktober 2020 werden alle neuen Repositorys auf GitHub mit dem main-Zweig erstellt. GitLab und Bitbucket haben ebenfalls Unterstützung für main als Standardnamen implementiert. Git 2.28 (Juli 2020) fügte die Option init.defaultBranch zum Konfigurieren des Standardzweignamens hinzu.

Technisch gesehen ist das Umbenennen eines vorhandenen Zweigs von master in main eine einfache Operation. Die Hauptherausforderung besteht darin, alle Verweise in CI/CD-Konfigurationen, Dokumentation und lokalen Repositorys der Entwickler zu aktualisieren.

Um einen Zweig in einem vorhandenen Repository umzubenennen, führen Sie Folgendes aus:

# Lokales Umbenennen von master in main
git branch -m master main

# Aktualisieren des entfernten Repositorys
git push -u origin main

# Löschen des alten master auf dem Server
git push origin --delete master

# Aktualisieren von HEAD auf dem Server
# (über GitHub-Weboberfläche: Settings → Branches → Default branch)

Rolle von main in Git Flow und GitHub Flow

Git Flow und GitHub Flow definieren die Rolle des main-Zweigs unterschiedlich. Die Wahl des Modells hängt von der Teamgröße, der Release-Häufigkeit und den Anforderungen an die Codestabilität ab.

Für die mobile Entwicklung ist Git Flow der Standard, da die Veröffentlichung einer App im App Store und bei Google Play feste Release-Zyklen hat. GitHub Flow eignet sich besser für Webprojekte, die mehrmals täglich bereitgestellt werden können.

GitHub Flow – vereinfachter Ansatz

In GitHub Flow gibt es keinen develop-Zweig. Alle Feature-Zweige werden direkt von main erstellt und nach Abschluss über einen Pull Request zurückgeführt. Jede Zusammenführung in main löst automatisch die Bereitstellung in der Produktion aus. Dieses Modell erfordert ein hohes Maß an Testautomatisierung und Teamdisziplin.

In GitHub Flow gibt es keinen develop-Zweig. Alle Feature-Zweige werden direkt von main erstellt und nach Abschluss über einen Pull Request zurückgeführt. Jede Zusammenführung in main löst automatisch die Bereitstellung in der Produktion aus. Dieses Modell erfordert ein hohes Maß an Testautomatisierung und Teamdisziplin.

Schutz des main-Branches

Branch-Schutz für main ist eine obligatorische Einstellung in jedem kommerziellen Projekt. Ohne ihn könnte ein versehentlicher Push unvollständigen Code in die Produktion senden oder eine funktionierende Anwendung für alle Benutzer beschädigen.

• Require pull request – direkter Push zu main ist verboten. Alle Änderungen über PR mit Überprüfung.
• Require approvals – mindestens 2 Genehmigungen für die Zusammenführung in main (falls ein Prüfer etwas übersieht).
• Require status checks – alle CI/CD-Prüfungen müssen vor der Zusammenführung erfolgreich sein.
• Require up-to-date – der PR muss auf dem neuesten main-Commit basieren.
• Include administrators – der Schutz gilt auch für Repository-Besitzer.
• Require signed commits – alle Commits in main müssen mit einem GPG-Schlüssel signiert sein.

Die Konfiguration aller sechs Regeln ist der Standard für mobile Projekte mit 10.000+ Benutzern. Für kleine Projekte reichen die ersten drei Regeln aus.

Vergleich der Schutzstufen für verschiedene Projekttypen

Die Schutzstufe von main hängt vom Projektumfang ab. Ein Startup kommt mit minimalem Schutz aus, während eine Unternehmensanwendung maximale Einschränkungen erfordert.

Releases und Tags in main

Tagging ist die Praxis, benannte Verweise auf bestimmte Commits in main zu erstellen. Jeder Tag entspricht einer in der Produktion veröffentlichten Version der Anwendung. Dies ermöglicht ein schnelles Umschalten auf jede vorherige Version zum Debuggen oder Patchen.

Der Standard für die Benennung von Tags in der mobilen Entwicklung ist SemVer (Semantische Versionierung): v1.2.3, wobei die erste Nummer die Hauptversion (breaking changes), die zweite die Nebenversion (neue Funktionen) und die dritte der Patch (Korrekturen) ist.

Ein Tag wird erstellt, nachdem der Release-Zweig in main zusammengeführt wurde. Dieser Commit wird dann in CI/CD erstellt, signiert und an den App Store gesendet. Wenn ein Fehler im Tag gefunden wird, wird ein Hotfix-Zweig von diesem Tag erstellt.

# Erstellen eines annotierten Release-Tags
git tag -a v2.4.1 -m "Release version 2.4.1"

# Senden des Tags an den Server
git push origin v2.4.1

# Alle Tags im Repository anzeigen
git tag -l "v2.*"

# Erstellen eines Hotfix-Zweigs von einem bestimmten Tag
git checkout -b hotfix/crash-fix v2.4.1

Git Flow Branch-Hierarchie

Das Verständnis der Branch-Hierarchie in Git Flow ist die Grundlage für die richtige Organisation der Zusammenarbeit. Jeder Branch-Typ hat seine eigene Quelle, seinen Zweck und seine Zusammenführungsregeln.

• Main (Ebene 1) – der Stammzweig, enthält nur Release-Versionen. Wird beim Initialisieren eines Repositorys erstellt.
• Develop (Ebene 2) – wird zu Projektbeginn von main erstellt. Enthält Integrationscode aller Funktionen.
• Feature (Ebene 3) – wird von develop erstellt. Isolierte Entwicklung einzelner Funktionen.
• Release (Ebene 2) – wird von develop erstellt. Vorbereitung einer bestimmten Version für die Veröffentlichung.
• Hotfix (Ebene 2) – wird von main erstellt. Dringende Korrekturen kritischer Produktionsfehler.

Wichtige Regel: Feature wird niemals direkt in main zusammengeführt. Feature → Develop → Release → Main ist die korrekte Zusammenführungskette. Ein Verstoß gegen diese Regel macht das gesamte Git-Flow-Modell sinnlos.

Befehlsbeispiele für die Arbeit mit main

Betrachten wir ein Szenario: Das Team hat die Vorbereitung des Releases v2.5.0 abgeschlossen. Der Release-Zweig wurde überprüft und ist bereit, in main zusammengeführt zu werden. Nach der Zusammenführung wird ein Tag erstellt und das Release veröffentlicht.

# Wechseln zu main und aktualisieren
git checkout main
git pull origin main

# Zusammenführen des verifizierten Release-Zweigs
git merge --no-ff release/2.5.0

# Erstellen eines Release-Tags
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Senden von main und Tag an den Server
git push origin main --tags

Das Flag --no-ff (no fast-forward) garantiert die Erstellung eines Merge-Commits, selbst wenn die Zusammenführung durch einfaches Verschieben des Zeigers hätte erfolgen können. Dies bewahrt die Information, dass die Änderungen von einem Release-Zweig kamen, was die Analyse des Verlaufs erleichtert.

Arbeiten mit Hotfix über main

Wenn ein kritischer Fehler in der Produktion entdeckt wird, unterscheidet sich der Prozess von einem normalen Release. Ein Hotfix wird von main erstellt und nach der Behebung sowohl in main als auch in develop zusammengeführt.

Wenn ein kritischer Fehler in der Produktion entdeckt wird, unterscheidet sich der Prozess von einem normalen Release. Ein Hotfix wird von main erstellt und nach der Behebung sowohl in main als auch in develop zusammengeführt.

# Erstellen eines Hotfix-Zweigs von main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Beheben und committen
git add src/fix/
git commit -m "Fix crash on login screen"

# Hotfix zurück in main zusammenführen
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Hotfix auch in develop zusammenführen
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Hotfix-Zweig löschen
git branch -d hotfix/2.5.1-crash-fix