Git-Workflows

Was ist ein Git-Workflow

Ein Git-Workflow ist ein vereinbarter Satz von Konventionen, wie ein Team Branches, Commits und Merges nutzt, um gemeinsam zu arbeiten, ohne sich gegenseitig in die Quere zu kommen. Git selbst ist meinungslos — es stellt die Werkzeuge bereit, schreibt aber nicht vor, wie man sie einsetzt. Ein Workflow schließt diese Lücke, indem er praktische Fragen beantwortet: Wo lebt neue Arbeit, wie wird sie überprüft und wie gelangt sie in die Produktion.

Warum es wichtig ist

Ohne einen gemeinsamen Workflow gerät ein Team schnell ins Chaos: halbfertige Arbeit auf dem Main-Branch, unerwartete Merge-Konflikte und Releases, die sich schwer reproduzieren lassen. Ein guter Workflow hält den Main-Branch jederzeit veröffentlichbar, macht Reviews zu einem natürlichen Schritt und gibt allen das gleiche mentale Modell davon, wo sich Code auf seinem Weg befindet.

Der zentralisierte Workflow

Das einfachste Modell — und eine gute Grundlage zum Verständnis der anderen — ist der zentralisierte Workflow: Alle committen direkt auf einen einzigen gemeinsamen Branch (normalerweise main). Es gibt keine Feature-Branches — git pull und git push halten jeden Entwickler mit dem zentralen Repository synchron.

# Get the latest shared history before you start
git pull origin main

# ...make and commit your changes...
git add .
git commit -m "Add user profile page"

# Share your work; rebase on top of any new commits first
git pull --rebase origin main
git push origin main

Das ist leicht zu verstehen, skaliert aber schlecht: Jeder Commit landet auf dem einen Branch, auf den Teammitglieder angewiesen sind, sodass eine unfertige Änderung alle blockieren kann. Die folgenden Workflows lösen das, indem sie Arbeit zunächst in Branches isolieren.

Die gängigen Workflows

Diese vier Ansätze bauen auf der zentralisierten Idee auf, fügen aber Isolation hinzu. Jeder macht unterschiedliche Kompromisse zwischen Einfachheit und Struktur:

Ein Feature-Branch in der Praxis

In der Praxis starten die meisten Teams mit Feature-Branches, weil die Befehle vertraut sind und die Isolation sofort eintritt. Das Muster ist immer dasselbe: von main abzweigen, die Arbeit erledigen und dann wieder zurückmergen.

# Create and switch to an isolated branch
git switch -c feature/login

# ...edit files, then stage and commit...
git add .
git commit -m "Add login form"

# Bring the finished work back into main
git switch main
git pull origin main          # make sure main is current
git merge feature/login       # integrate the feature
git push origin main

Der Branch hält main veröffentlichbar, während das Feature noch halbfertig ist, und gibt Reviewern einen in sich geschlossenen Satz von Commits zum Lesen.

Pull Requests auf jedem Workflow

Auf gehosteten Plattformen wie GitHub, GitLab oder Bitbucket mergst du normalerweise nicht lokal. Stattdessen pushst du den Branch und öffnest einen Pull Request (auf GitLab „Merge Request" genannt): ein Ort, um das Diff zu überprüfen, CI auszuführen und zu diskutieren, bevor der Code main erreicht.

git switch -c feature/login
# ...commit work...
git push -u origin feature/login   # push branch, set upstream
# then open a pull request in the web UI

Pull Requests sind kein separater Workflow — sie sind ein Review-Gate, das du auf das Feature-Branch-, Gitflow-, Trunk-based- oder Forking-Modell gleichermaßen anwenden kannst.

Wie man wählt

Beginne mit dem einfachsten Workflow, der zu deiner Situation passt, und füge Struktur nur dann hinzu, wenn du den Schmerz spürst, sie nicht zu haben.

• Ein kleines Team, das kontinuierlich eine Web-App ausliefert, ist mit dem Feature-Branch- oder Trunk-based-Ansatz gut bedient.
• Ein Produkt mit versionierten, geplanten Releases profitiert von Gitflows expliziten Release- und Hotfix-Branches.
• Ein Open-Source-Projekt, das Beiträge von Fremden entgegennimmt, benötigt das Forking-Modell, da Mitwirkende keinen Push-Zugriff auf das Haupt-Repository haben.

Diese Workflows schließen sich nicht gegenseitig aus. Viele Teams kombinieren Ideen — zum Beispiel kurzlebige Feature-Branches mit einer Trunk-based-Denkweise, oder Pull Requests auf jedem von ihnen.

Der gemeinsame Faden

Jeder Workflow hier baut auf denselben Grundbausteinen auf, die du bereits kennst: git branch, git switch, git merge, git rebase und git push. Der Workflow ist nur eine Konvention, die über diese Befehle gelegt wird. Beherrsche die Befehle, einigt euch auf die Konventionen, und die Zusammenarbeit wird deutlich reibungsloser.

Übung