Branching
Bisher hast du auf einem Branch gearbeitet (main). In dieser Lektion lernst du parallele Entwicklungslinien aufzumachen – das vielleicht stärkste Git-Feature. Branches ermöglichen Features parallel zu entwickeln, Experimente zu wagen, Bugfixes isoliert zu testen.
In Git ist Branching billig: ein Branch ist nur ein 41-Byte-File (Pointer auf einen Commit). Im Gegensatz zu SVN, wo Branches teure Kopien sind, kannst du in Git täglich Dutzende aufmachen. Diese Lektion zeigt wie.
1) Was ist ein Branch wirklich?
Aus L2: ein Branch ist nur ein Pointer auf einen Commit. Physisch ist es eine kleine Datei in .git/refs/heads/<branchname> mit dem SHA-Hash drin. Beim Commiten bewegt sich der aktuelle Branch automatisch zum neuen Commit.
Diese Einfachheit ist der Grund, warum Branching so schnell ist. SVN kopiert beim Branchen das ganze Repository (teuer). Git ändert einen Pointer (instant).
2) Branch-Visualisierung – durch eine Story klicken
Eine typische Feature-Branch-Story Schritt für Schritt. Klick „Weiter" und folge dem Geschehen:
main. Es gibt 2 Commits. HEAD zeigt auf main. Klick „Weiter".git switch feature bewegt HEAD. Beim Commiten bewegt sich der aktuelle Branch (und HEAD mit). Beim Merge entsteht oft ein neuer Commit mit zwei Eltern (Merge-Commit). Diese Mechanik ist die Grundlage für jede Branching-Strategie.3) Die wichtigsten Branch-Befehle
| Befehl | Was er tut |
|---|---|
| git branch | Listet lokale Branches (aktueller mit *). |
| git branch -a | Listet lokale + Remote-Branches. |
| git branch <name> | Erstellt einen neuen Branch. Wechselt nicht hin. |
| git switch <name> | Wechselt zum Branch. (Modern, seit Git 2.23.) |
| git switch -c <name> | Erstellt UND wechselt zum neuen Branch. |
| git checkout <name> | Älterer Befehl, funktioniert weiter. |
| git merge <branch> | Führt <branch> in aktuellen Branch ein. |
| git branch -d <name> | Löscht Branch (nur wenn gemerged). |
| git branch -D <name> | Erzwungenes Löschen – Datenverlust möglich! |
| git log --graph --oneline --all | Alle Branches als ASCII-Graph. |
git switch und git restore als modernere Alternativen zu git checkout. checkout machte zu viel auf einmal (Branch wechseln, Datei wiederherstellen, neuen Branch erstellen). Heute: switch für Branches, restore für Dateien. checkout bleibt aber überall verfügbar.4) Der Feature-Branch-Workflow
Der häufigste Workflow im Team. Jedes Feature, jeder Bugfix bekommt einen eigenen Branch:
git switch main && git pull – auf neuestem Stand starten.git switch -c feature/login-button – neuer Branch von main.git add, git commit. Kleine Commits sind OK.git push -u origin feature/login-button – beim ersten Mal mit -u.git switch main && git pull && git branch -d feature/login-button5) Branch-Namen – Konventionen
/) als Trenner – funktioniert in Git wie Pseudo-Ordner und gruppiert Branches in Tools. Kleinbuchstaben, Bindestriche (nicht Unterstriche), keine Sonderzeichen. Ein guter Name wird in Tools, PRs, CI-Logs lesbar.6) Branch-Typen nach Verwendung
7) Branches aufräumen
Branches lokal löschen ist wichtig – sonst hast du irgendwann 50 Branches. Befehle:
git branch -d <branch>– sicheres Löschen, nur wenn gemerged.git branch -D <branch>– Erzwingen, auch ungemerged. Vorsicht!git push origin --delete <branch>– Branch auf Remote löschen.git fetch --prune– lokale Referenzen zu gelöschten Remote-Branches entfernen.
Tipp: in GitHub-Settings „Automatically delete head branches" aktivieren – nach Merge eines PRs wird der Branch automatisch entfernt.
8) Detached HEAD – was tun?
Manchmal landest du im „Detached HEAD"-Zustand – HEAD zeigt nicht auf einen Branch, sondern direkt auf einen Commit. Passiert beim Checkout eines Tags oder alten Commits.
Du kannst hier commiten, aber kein Branch zeigt auf diese Commits. Sobald du wegswitchst, sind sie verloren. Sichere Lösungen:
- Nur schauen: einfach
git switch main, du bist wieder zuhause. - Commits behalten: sofort einen neuen Branch erstellen:
git switch -c neuer-branch. Jetzt sind die Commits sicher.
9) Best Practices
- Branches kurzlebig halten. Feature-Branch sollte 1-7 Tage existieren, nicht 3 Monate. Sonst driftet er weit vom main weg.
- Regelmäßig main einholen. Bei längeren Branches:
git pull origin mainodergit rebase main(siehe L6). - Niemals direkt auf main commiten. In professionellen Teams über Branch-Protection-Rules abgesichert. Alles geht über PRs.
- Branches lokal aufräumen. Nach Merge: lokal löschen.
- Ein Branch = eine Aufgabe. Nicht mehrere Features mischen – Reviews werden unleserlich.
10) Branch vs. Tag – der Unterschied
Beides sind Pointer auf Commits, aber:
- Branch bewegt sich mit neuen Commits. Dynamisch.
- Tag bleibt für immer auf demselben Commit. Statisch. Ideal für Releases (
v1.0.0).
Tags erstellen: git tag v1.0.0 oder mit Nachricht git tag -a v1.0.0 -m "Release 1.0". Pushen explizit mit git push --tags. Tags sind besonders nützlich für SemVer-Releases.
Zusammenfassung
Branch = Pointer auf einen Commit, billig in Git. Wichtige Befehle: git branch (auflisten), git switch -c (neu + wechseln), git merge (zusammenführen), git branch -d (löschen). Feature-Branch-Workflow: main pullen → branch → arbeiten → push -u → PR → merge → aufräumen. Naming: feature/..., fix/..., hotfix/..., refactor/.... Branches kurzlebig halten, niemals direkt auf main. Nächste Lektion: Merge vs. Rebase.