Feature-Branch-Workflow

Überblick

Der Feature-Branch-Workflow ist die häufigste Art, wie Teams mit Git zusammenarbeiten. Die Regel ist einfach: Alle Entwicklung findet auf dedizierten Branches statt, niemals direkt auf main. Jedes neue Feature, jede Korrektur oder jedes Experiment erhält seinen eigenen Branch, und der main-Branch empfängt nur fertige, geprüfte Arbeit. Dadurch bleibt main jederzeit stabil und auslieferbar.

Die Grundidee

Da die Arbeit auf Branches isoliert ist, können mehrere Personen gleichzeitig verschiedene Features entwickeln, ohne sich gegenseitig zu beeinflussen. main fungiert als einzige Quelle der Wahrheit für produktionsbereiten Code. Ein Branch ist eine fokussierte Arbeitseinheit mit einem klaren Anfang (erstellt von main) und einem klaren Ende (zurück in main gemergt).

Entscheidend ist, dass ein Branch in Git günstig ist: Er ist lediglich ein beweglicher Zeiger auf einen Commit, keine Kopie deiner Dateien. Das Erstellen erfolgt sofort und belegt kaum Speicherplatz – genau deshalb ist es praktisch, pro Aufgabe einen Branch anzulegen.

Branches benennen

Ein einheitliches Benennungsschema macht Branches selbstdokumentierend. Die meisten Teams stellen dem Branch-Namen seinen Typ voran und referenzieren die bearbeitete Aufgabe:

feature/login-form
feature/W3-142-checkout-page
fix/null-pointer-on-logout
chore/upgrade-eslint

Der Schrägstrich ist nur eine Konvention – Git behandelt feature/login-form als einen einzelnen Branch-Namen, obwohl er Tools erlaubt, Branches nach Präfix zu gruppieren. Vermeide Leerzeichen und Großbuchstaben, damit die Namen leicht einzutippen sind.

Ein Schritt-für-Schritt-Beispiel

Der Workflow ist eine kurze, wiederholbare Schleife: Von main abzweigen, arbeiten, pushen, reviewen, mergen, aufräumen.

1. Den Branch von einem aktuellen main erstellen

Starte immer vom neuesten main, damit dein Branch auf dem aktuellen Code basiert:

git switch main
git pull
git switch -c feature/login-form

git switch -c erstellt den Branch und checkt ihn in einem Schritt aus (die ältere Entsprechung ist git checkout -b). Siehe git switch für den vollständigen Befehl.

2. Arbeiten und dabei committen

Committe in kleinen, logischen Schritten statt in einem riesigen Commit am Ende – kleine Commits sind einfacher zu reviewen und rückgängig zu machen:

git add login.html login.js
git commit -m "Add login form markup and validation"

Bevorzuge das Stagen einzelner Dateien gegenüber git add ., damit du nicht versehentlich unzusammenhängende Änderungen commitest. Erfahre mehr über das Erstellen guter Commits in git commit.

3. Den Branch pushen

Pushe den Branch, damit Teammitglieder deine Arbeit sehen können und du einen Pull Request öffnen kannst. Das Flag -u verknüpft deinen lokalen Branch mit dem Remote-Branch, sodass du später einfach git push eingeben kannst:

git push -u origin feature/login-form

Siehe git push, was -u (--set-upstream) im Detail bewirkt.

Review und Merge

Auf einer Hosting-Plattform wie GitHub oder GitLab öffnest du einen Pull Request (PR), auf GitLab als Merge Request bezeichnet. Hier reviewen Teammitglieder den Diff, hinterlassen Kommentare und genehmigen. Continuous-Integration-(CI-)Prüfungen führen die Test-Suite typischerweise automatisch gegen den Branch aus. Sobald der PR genehmigt und die Prüfungen grün sind, wird der Branch in main gemergt.

Diese Plattformen bieten drei gängige Merge-Strategien an:

• Merge-Commit – bewahrt jeden Commit auf dem Branch plus einen Merge-Commit. Behält die vollständige Historie, kann aber unübersichtlich werden.
• Squash and Merge – fasst alle Branch-Commits zu einem einzigen Commit auf main zusammen. Beliebt, weil main sauber bleibt und jedes Feature einen einzelnen Eintrag darstellt.
• Rebase and Merge – spielt die Branch-Commits ohne Merge-Commit auf main zurück und erzeugt so eine lineare Historie.

Nach dem Merge aufräumen

Sobald der Branch gemergt ist, lösche ihn lokal und remote, damit das Repository nicht mit veralteten Branches gefüllt wird:

git switch main
git pull
git branch -d feature/login-form        # delete the local branch
git push origin --delete feature/login-form   # delete the remote branch

git branch -d verweigert das Löschen eines Branches, der noch nicht gemergt wurde, und schützt dich so vor dem Verlust von Arbeit. (Verwende -D zum erzwungenen Löschen, wenn du sicher bist.)

Einen Branch aktuell halten

Wenn main sich weiterentwickelt, während du arbeitest, übernimm diese Änderungen in deinen Branch, damit der spätere Merge reibungslos verläuft und Konflikte frühzeitig sichtbar werden. Du hast zwei Möglichkeiten:

# Option A — merge main into your branch (keeps history as-is)
git switch feature/login-form
git merge main

# Option B — rebase your branch onto the latest main (linear history)
git switch feature/login-form
git rebase main

Mergen ist nicht-destruktiv und sicher für gemeinsam genutzte Branches, fügt aber Merge-Commits hinzu. Rebasen erzeugt eine sauberere, lineare Historie, schreibt die Commits deines Branches jedoch um – vermeide deshalb das Rebasen eines Branches, den andere bereits gepullt haben. Die Faustregel: Rebase deinen eigenen privaten Branch, merge alles Gemeinsam-Genutzte.

Konflikte behandeln

Wenn zwei Branches dieselben Zeilen ändern, hält der Merge oder Rebase an und fordert dich auf, den Konflikt zu lösen. Git markiert die kollidierenden Bereiche in den betroffenen Dateien; du bearbeitest sie, stagst sie und setzt dann fort. Der vollständige Prozess wird in Merge-Konflikte lösen beschrieben.

Arbeit im Entstehen sichern

Wenn du Branches wechseln musst, aber noch nicht bereit bist zu committen, legt git stash deine nicht committeten Änderungen beiseite, sodass du dich frei bewegen und sie später wiederherstellen kannst:

git stash            # set current changes aside
git switch main      # do something urgent
git switch feature/login-form
git stash pop        # bring the changes back

Vorteile und Abwägungen

Der Feature-Branch-Workflow ist beliebt, weil er leicht zu verstehen ist, sich natürlich mit Pull Requests und Code-Review integriert und main jederzeit auslieferbar hält.

Das Hauptrisiko sind langlebige Branches: Je länger ein Branch existiert, desto mehr weicht er von main ab und desto schwieriger wird der spätere Merge ("Merge-Hölle"). Um das zu vermeiden:

• Halte Branches klein und kurzlebig – idealerweise innerhalb von ein oder zwei Tagen gemergt.
• Pulle main in deinen Branch (oder rebase) regelmäßig, nicht erst am Ende.
• Teile große Features in mehrere kleinere Branches auf, die jeweils unabhängig gemergt werden.
• Committe niemals direkt auf main – das untergräbt den Sinn des Workflows.

Wenn Teams auf dieser Basis Release-Branches, Hotfix-Branches und einen strengen Promotion-Prozess benötigen, greifen sie oft auf ein umfassenderes Modell wie Git Flow oder Trunk-Based Development zurück – aber der Feature-Branch ist der Baustein, auf dem sie alle aufbauen.

Übungen