Git-Workflows: Feature Branches und Git Flow

Git gibt dir die Werkzeuge an die Hand, aber wie du sie im Team einsetzt, bestimmt ein Workflow. Ein guter Workflow sorgt dafür, dass alle nach denselben Regeln arbeiten, Releases planbar sind und der Hauptzweig stabil bleibt. In diesem Beitrag schauen wir uns die wichtigsten Ansätze an: Feature Branches, Git Flow und GitHub Flow.

Warum überhaupt ein Workflow?

Ohne klare Regeln entsteht schnell Chaos: Niemand weiß, wo neue Features hingehören, wann ein Release passiert oder wie Hotfixes eingespielt werden. Ein Workflow ist eine Vereinbarung, wie Branches genutzt werden. Er ist kein technischer Zwang, sondern eine gemeinsame Konvention im Team.

Welcher Workflow der richtige ist, hängt von der Teamgröße, der Release-Frequenz und der Art des Projekts ab.

Der Feature-Branch-Workflow

Der einfachste verbreitete Ansatz: Für jedes Feature und jeden Bugfix gibt es einen eigenen Branch, der von main abzweigt und nach dem Review wieder zurückfließt. Der Hauptzweig bleibt dabei immer in einem funktionierenden Zustand.

# Vom aktuellen main starten
git switch main
git pull

# Feature-Branch erstellen
git switch -c feature/warenkorb

# Nach der Arbeit pushen
git push -u origin feature/warenkorb

Die Benennung mit einem Präfix wie feature/ sorgt für Ordnung. So erkennst du auf einen Blick, worum es bei einem Branch geht.

GitHub Flow: schlank und schnell

GitHub Flow ist eine leichtgewichtige Variante, ideal für Projekte mit häufigen Deployments. Es gibt nur main und kurzlebige Feature-Branches. Sobald ein Feature gemergt ist, wird sofort deployt.

# Branch für eine Änderung
git switch -c fix/login-bug

# Committen und pushen
git commit -am "Login-Fehler behoben"
git push -u origin fix/login-bug

# Nach Merge des Pull Requests: main aktualisieren
git switch main
git pull

Dieser Ansatz passt hervorragend zu Continuous Deployment, bei dem jede Änderung schnell live geht. Es gibt keine langlebigen Branches, die gepflegt werden müssen.

Git Flow: strukturiert mit festen Rollen

Git Flow ist umfangreicher und eignet sich für Projekte mit geplanten Releases. Es definiert mehrere langlebige Branches: main für veröffentlichte Versionen und develop als Integrationszweig. Dazu kommen feature/, release/ und hotfix/-Branches.

# Feature startet von develop
git switch develop
git switch -c feature/zahlungsmodul

# Release vorbereiten
git switch develop
git switch -c release/1.2.0

# Hotfix direkt von main
git switch main
git switch -c hotfix/sicherheitsluecke

Der release/-Branch dient dazu, eine Version stabil zu machen, ohne die Weiterentwicklung auf develop zu blockieren. hotfix/-Branches lösen dringende Probleme direkt auf der Produktionsversion.

Welchen Workflow solltest du wählen?

Es gibt nicht den einen perfekten Workflow. Die Wahl hängt von deinem Projekt ab. Diese Faustregeln helfen dir bei der Entscheidung.

• Allein oder im kleinen Team: Feature-Branch-Workflow oder GitHub Flow reichen völlig.
• Häufige Deployments: GitHub Flow, weil er schlank und schnell ist.
• Geplante Releases mit Versionen: Git Flow gibt klare Struktur.
• Open-Source-Projekte: meist Feature-Branches mit Pull Requests von Forks.

Im Zweifel gilt: Fang einfach an. Du kannst einen Workflow später immer noch erweitern, wenn das Projekt wächst.

Commits sinnvoll benennen

Egal welcher Workflow, gute Commit-Nachrichten sind Gold wert. Eine verbreitete Konvention sind die sogenannten Conventional Commits.

# Neues Feature
git commit -m "feat: Warenkorb-Anzeige hinzugefügt"

# Fehlerbehebung
git commit -m "fix: Rundungsfehler bei Preisen korrigiert"

# Dokumentation
git commit -m "docs: README um Installationsschritte ergänzt"

Diese Präfixe machen die Historie lesbar und lassen sich sogar automatisch auswerten, etwa für die Erstellung von Änderungsprotokollen.

Fazit

Ein Git-Workflow ist die gemeinsame Sprache deines Teams. Für die meisten Einsteiger und kleine Projekte sind Feature Branches oder GitHub Flow die beste Wahl, weil sie einfach und flexibel sind. Git Flow lohnt sich, sobald du mit festen Versionen und geplanten Releases arbeitest. Wichtig ist vor allem, dass sich alle an dieselben Regeln halten. Probiere einen Ansatz in deinem nächsten Projekt aus und passe ihn an deine Bedürfnisse an.