Git-Branches richtig nutzen: Warum main, checkout -b & push -u entscheidend sind

Git ist ein mächtiges Werkzeug für die Versionsverwaltung, doch viele Entwickler nutzen Befehle wie git branch -M main, git checkout -b oder git push -u einfach auswendig – ohne zu wissen, warum sie funktionieren. Doch genau dieses Unwissen führt oft zu Fehlern: Branches landen am falschen Ort, Commits werden verwechselt oder lokale und entfernte Branches passen nicht zusammen.

Dieser Artikel klärt die häufigsten Missverständnisse und zeigt, wie Sie Git-Branches richtig einsetzen – von der Erstellung über das Umbenennen bis hin zum Hochladen auf den Remote-Server.

Warum git branch -M main mehr ist als nur ein Befehl

Der Befehl git branch -M main wird oft falsch interpretiert. Viele glauben, er würde einen magischen "main" auf GitHub erstellen – doch das stimmt nicht. Tatsächlich benennt dieser Befehl die aktuelle lokale Branch um.

Der Schlüssel liegt in der Option -M:

• -m steht für "move" und benennt einen Branch um.
• -M ist die erzwungene Variante, die auch bei Namenskonflikten funktioniert.

Wenn Sie also git branch -M main ausführen, sagen Sie Git: „Nimm den Branch, auf dem ich gerade arbeite, und benenne ihn in `main` um.“

Was passiert bei älteren Repositories mit master?

Früher verwendeten viele Projekte den Namen master als Standard-Branch. Der Befehl funktioniert analog:

git branch -M master

Der Unterschied liegt nur im Zielnamen. Moderne Repositories nutzen jedoch meist main, um sich von veralteten Konventionen zu lösen.

Der optimale Start für neue Projekte

Wenn Sie ein neues Repository initialisieren, können Sie direkt den gewünschten Standard-Branch festlegen:

git init -b main

Dieser Befehl erstellt sofort einen main-Branch und vermeidet spätere Umbenennungen.

git checkout -b vs. git switch -c: Zwei Wege, ein Ziel

Beide Befehle dienen demselben Zweck: Sie erstellen einen neuen Branch und wechseln direkt dorthin. Doch warum gibt es zwei Varianten?

Die klassische Herangehensweise mit checkout

git checkout -b feature/login-seite

Der Befehl checkout ist ein Allzweck-Werkzeug in Git. Er kann nicht nur Branches wechseln, sondern auch Dateien wiederherstellen oder durch die Commit-Historie navigieren. Diese Vielseitigkeit ist zwar nützlich, aber auch verwirrend für Einsteiger.

Die moderne Alternative: git switch

git switch -c feature/login-seite

Der Befehl switch wurde eingeführt, um die Absicht klarer zu machen. Während checkout viele Funktionen vereint, ist switch ausschließlich für Branch-Operationen zuständig. Das macht den Code leichter lesbar und verständlich – besonders in Teams oder bei der Einarbeitung neuer Entwickler.

Welche Variante sollten Sie verwenden?

Wenn Sie mit einer aktuellen Git-Version (2.23 oder neuer) arbeiten, ist git switch die bessere Wahl:

• Klare Syntax
• Einfacher zu lehren
• Weniger Fehleranfällig

Für ältere Projekte oder wenn switch nicht verfügbar ist, bleibt checkout -b eine funktionierende Alternative.

Warum git push -u origin feature/branch unverzichtbar ist

Ein lokaler Branch existiert erst dann für andere sichtbar, wenn er auf den Remote-Server hochgeladen wird. Der Befehl git push -u kombiniert dabei zwei wichtige Schritte:

1. Hochladen des Branches auf den Remote-Server

git push -u origin feature/login-seite

Dieser Befehl sendet Ihren lokalen Branch feature/login-seite zum Remote mit dem Namen origin.

2. Festlegen der Upstream-Beziehung

Das -u (kurz für --set-upstream) ist entscheidend: Es verknüpft Ihren lokalen Branch mit dem entfernten Branch. Dadurch können Sie später einfach

git push

oder

git pull

ohne den vollständigen Branch-Namen angeben zu müssen. Git weiß automatisch, wohin Commits gesendet werden sollen.

Ohne dieses -u müssten Sie bei jedem Push den vollständigen Befehl wiederholen:

git push origin feature/login-seite

Das ist nicht nur umständlich, sondern führt auch schnell zu Fehlern.

Der ideale Arbeitsablauf für Einsteiger

Für die meisten Projekte reicht ein einfacher, konsistenter Workflow. Hier die empfohlene Abfolge:

Für ein neues Repository

git init -b main
git add .
git commit -m "Erster Commit"
git switch -c feature/login-seite
git push -u origin feature/login-seite

Für ein bestehendes Repository (mit Umbenennung)

git init
git branch -M main
git add .
git commit -m "Erster Commit"
git switch -c feature/login-seite
git push -u origin feature/login-seite

Dieser Ablauf deckt die meisten Anwendungsfälle ab – von persönlichen Projekten bis hin zu Teamarbeit.

GitHub CLI (gh) als Ergänzung – aber kein Ersatz

Das Tool gh (GitHub CLI) vereinfacht viele GitHub-spezifische Aufgaben, ersetzt aber nicht die Kernbefehle für Branches.

Wo gh hilft

Mit gh können Sie ein neues Repository direkt aus der Kommandozeile erstellen und mit Ihrem lokalen Projekt verknüpfen:

gh repo create mein-projekt --public --source=. --remote=origin --push

Dieser Befehl erledigt drei Dinge auf einmal:

• Erstellt das Repository auf GitHub.
• Verknüpft es als origin.
• Lädt den lokalen Code hoch.

Wo Sie bei Git bleiben sollten

Für die tägliche Arbeit mit Branches bleibt Git unverzichtbar:

git switch -c feature/login-seite
git push -u origin feature/login-seite

Wann gh besonders nützlich wird

Sobald der Branch existiert, vereinfacht gh das Erstellen von Pull Requests:

gh pr create --base main --head feature/login-seite --title "Login-Seite implementieren" --body "Diese PR fügt die grundlegende Login-Funktionalität hinzu."

Teams, die GitHub Issues nutzen, profitieren zudem von einem Workflow, bei dem Branches direkt mit Issues verknüpft werden können.

Der häufigste Fehler: Befehle auswendig lernen statt verstehen

Viele Entwickler stolpern immer wieder über dieselben Probleme:

• „Warum erscheint mein Branch nicht auf GitHub?“
• „Warum sagt `git push`, dass kein Upstream-Branch existiert?“
• „Warum habe ich lokal `master` und remote `main`?“

Die Antwort liegt fast immer im Missverständnis des Branch-Lebenszyklus:

1. Repository erstellen → Standard-Branch festlegen (main oder master).
2. Feature-Branch erstellen → Lokal oder remote.
3. Branch hochladen und Upstream verknüpfen → Mit push -u.
4. Pull Request erstellen → Für die Code-Review.

Wenn Sie diesen Ablauf verinnerlichen, werden Git-Befehle plötzlich logisch – statt wie willkürliche Abfolgen zu wirken.

Fazit: Git verstehen statt nur zu tippen

Der Schlüssel zu einem reibungslosen Git-Erlebnis liegt nicht darin, Befehle auswendig zu lernen, sondern den Arbeitsablauf zu verstehen. Hier die wichtigsten Erkenntnisse:

• git branch -M main → Benennt den aktuellen Branch um – nicht mehr und nicht weniger.
• git checkout -b name oder git switch -c name → Erstellt einen neuen Branch und wechselt direkt dorthin. Moderne Projekte nutzen bevorzugt switch.
• git push -u origin name → Lädt den Branch hoch und setzt die Upstream-Beziehung. Ohne -u wird der Workflow umständlich.
• gh → Hilft bei Repository-Erstellung und Pull Requests, ersetzt aber nicht Git-Branches.

Git wird erst dann zu einem zuverlässigen Werkzeug, wenn Sie aufhören, Befehle mechanisch einzutippen – und stattdessen verstehen, wie die Versionsverwaltung wirklich funktioniert. Dann verschwinden plötzliche Fehler, und der gesamte Prozess wird vorhersehbar.