Git-Workflow-Leitfaden: Branching-Strategien für Teams

· 12 Min. Lesezeit

📑 Inhaltsverzeichnis

Git ist der unbestrittene König der Versionskontrolle und wird von über 95 % der Entwicklungsteams weltweit verwendet. Aber Git-Befehle zu kennen ist nur die halbe Miete – die eigentliche Herausforderung besteht darin, eine Branching-Strategie zu wählen und konsequent zu befolgen, die für Ihr Team funktioniert.

Ein guter Git-Workflow verhindert Merge-Konflikte, ermöglicht parallele Entwicklung, erhält die Codequalität und macht Releases vorhersehbar. Ohne einen solchen riskieren Sie Chaos, fehlerhafte Builds und frustrierte Entwickler.

Warum Git-Workflows wichtig sind

Stellen Sie sich vor: Es ist Freitagnachmittag, und Ihr Team hat gerade einen kritischen Bugfix in die Produktion gebracht. Aber warten Sie – jemand anderes hat gleichzeitig ein ungetestetes Feature direkt in main gemergt. Jetzt ist die Produktion kaputt, niemand weiß, welcher Commit das Problem verursacht hat, und Ihre Wochenendpläne sind ruiniert.

Dieses Szenario spielt sich in Teams ohne definierte Git-Workflows ab. Hier ist, was schiefläuft:

Ein gut definierter Git-Workflow legt klare Regeln fest, wann gebrancht, wie gemergt und wer Änderungen genehmigt. Er schafft ein gemeinsames Verständnis in Ihrem Team darüber, wie Code von der Entwicklung zur Produktion gelangt.

Profi-Tipp: Der beste Workflow ist der, den Ihr Team tatsächlich befolgt. Fangen Sie einfach an und fügen Sie nur dann Komplexität hinzu, wenn Sie sie brauchen. Ein einfacher Workflow, den jeder versteht, schlägt einen ausgefeilten, den niemand befolgt.

Feature-Branch-Workflow

Der Feature-Branch-Workflow ist der am weitesten verbreitete Git-Workflow, und das aus gutem Grund. Er ist einfach, flexibel und funktioniert für Teams jeder Größe. Das Kernprinzip: Jedes neue Feature oder jeder Bugfix bekommt seinen eigenen Branch, der von main erstellt wird.

Entwickler arbeiten isoliert an ihren Feature-Branches und erstellen dann nach dem Code-Review einen Pull Request, um zurück in main zu mergen. Dies hält main stabil und jederzeit deploybar.

Wie es funktioniert

Hier ist der typische Ablauf zum Hinzufügen eines neuen Features:

# Von main starten und neueste Änderungen holen
git checkout main
git pull origin main

# Einen neuen Feature-Branch erstellen
git checkout -b feature/user-authentication

# Änderungen vornehmen und committen
git add .
git commit -m "feat: add login form validation"

# Zum Remote pushen
git push origin feature/user-authentication

# PR auf GitHub/GitLab für Code-Review erstellen
# Nach Genehmigung in main mergen
# Feature-Branch löschen

Namenskonventionen für Branches

Konsistente Benennung macht es einfach zu verstehen, was jeder Branch tut. Hier sind gängige Präfixe:

Wann der Feature-Branch-Workflow verwendet werden sollte

Dieser Workflow glänzt, wenn:

Potenzielle Fallstricke

Achten Sie auf diese häufigen Probleme:

Schneller Tipp: Halten Sie Feature-Branches kurzlebig (idealerweise weniger als 3 Tage). Wenn ein Feature länger dauert, teilen Sie es in kleinere Teile auf, die schrittweise hinter Feature Flags gemergt werden können.

GitFlow-Workflow

GitFlow ist ein strukturierterer Workflow, der für Projekte mit geplanten Releases konzipiert ist. Er verwendet mehrere langlebige Branches, um verschiedene Phasen der Entwicklung und Release-Vorbereitung zu verwalten.

GitFlow wurde 2010 von Vincent Driessen entwickelt und wurde bei Teams beliebt, die Software nach einem regelmäßigen Release-Zeitplan (monatlich, quartalsweise usw.) ausliefern. Es bietet eine klare Trennung zwischen Entwicklung, Release-Vorbereitung und Produktionscode.

Die Branch-Struktur

GitFlow verwendet fünf Arten von Branches:

Der vollständige GitFlow-Zyklus

So fließt Code durch GitFlow:

# GitFlow initialisieren (einmalige Einrichtung)
git flow init

# Ein neues Feature starten
git flow feature start user-profile
# Am Feature arbeiten...
git flow feature finish user-profile
# Mergt automatisch in develop

# Ein Release starten, wenn develop bereit ist
git flow release start 1.2.0
# Nur Bugfixes und Versionsaktualisierungen
git flow release finish 1.2.0
# Mergt in main und develop, erstellt Tag

# Notfall-Hotfix
git flow hotfix start security-patch
# Problem beheben...
git flow hotfix finish security-patch
# Mergt in main und develop

Wann GitFlow Sinn macht

GitFlow funktioniert gut für:

Warum GitFlow in Ungnade fiel

Viele moderne Teams haben sich von GitFlow abgewandt, weil:

Selbst Vincent Driessen, der Erfinder von GitFlow, empfiehlt jetzt einfachere Workflows für die meisten Webanwendungen, die kontinuierlich deployen.

Trunk-Based Development

Trunk-Based Development (TBD) ist der Workflow, der von leistungsstarken Engineering-Teams bei Google, Facebook und Netflix verwendet wird. Es ist das Gegenteil von GitFlow – anstelle von langlebigen Branches committen Entwickler direkt in main (den "Trunk") oder verwenden sehr kurzlebige Feature-Branches.

Das Schlüsselprinzip: Code häufig integrieren (mehrmals täglich), um den Schmerz großer Merges zu vermeiden.

Wie Trunk-Based Development funktioniert

Es gibt zwei Varianten von TBD:

Direkte Commits nach main:

# Neueste Änderungen holen
git pull origin main

# Kleine Änderungen vornehmen
git add .
git commit -m "feat: add email validation"

# Direkt nach main pushen
git push origin main

Kurzlebige Feature-Branches (für die meisten Teams empfohlen):

# Branch für kleine Änderung erstellen
git checkout -b add-email-validation

# Änderungen vornehmen und committen
git add .
git commit -m "feat: add email validation"

# Pushen und PR erstellen
git push origin add-email-validation

# Innerhalb von 24 Stunden mergen, Branch löschen

Die Rolle von Feature Flags

Trunk-Based Development stützt sich stark auf Feature Flags (auch Feature Toggles genannt), um unvollständige Features vor Benutzern zu verbergen. Dies ermöglicht es Ihnen, Code in main zu mergen, bevor er für die Produktion bereit ist.

// Feature-Flag-Beispiel
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckoutFlow />;
}
return <OldCheckoutFlow />;

Mit Feature Flags können Sie:

Voraussetzungen für erfolgreiches TBD

Trunk-Based Development erfordert starke Engineering-Praktiken:

Vorteile von Trunk-Based Development

Richtig gemacht, bietet TBD erhebliche Vorteile:

Profi-Tipp: Springen Sie nicht direkt zu Trunk-Based Development, wenn Ihr Team neu bei CI/CD ist. Bauen Sie zuerst Ihre Test-Infrastruktur und Deployment-Automatisierung auf und verkürzen Sie dann schrittweise die Lebensdauer Ihrer Feature-Branches.

Den richtigen Workflow für Ihr Team wählen

Es gibt keine Einheitslösung. Der richtige Workflow hängt von Ihrer Teamgröße, Release-Kadenz und Engineering-Reife ab. So entscheiden Sie:

Workflow Am besten für Teamgröße Release-Kadenz
Feature Branch Web-Apps, SaaS-Produkte, die meisten modernen Teams Jede Größe Kontinuierlich oder wöchentlich
GitFlow Desktop-/Mobile-Apps, versionierte Releases Mittel bis groß Monatlich oder quartalsweise
Trunk-Based Hochgeschwindigkeits-Teams mit starker CI/CD Jede Größe (mit Disziplin) Mehrmals täglich

Entscheidungsrahmen

Stellen Sie sich diese Fragen:

1. Wie oft deployen Sie in die Produktion?

2. Wie ausgereift ist Ihre CI/CD-Pipeline?