Git Workflows

6 Kernkonzepte

Die wichtigsten Git Workflows für die Zusammenarbeit: Git Flow · GitHub Flow · Trunk-Based · Feature Branches · Release Branches · Hotfixes Git Workflows definieren, wie Teams mit Branches, Commits und Releases umgehen. Die Wahl des richtigen Workflows ist entscheidend für eine effiziente und fehlerfreie Zusammenarbeit.

Git Flow – Klassisches Branching-Modell

develop · main · feature · release · hotfix

# Hauptbranches main # Produktions-Code (nur Releases) develop # Entwicklung (Integration) # Unterstützende Branches feature/* # Neue Features release/* # Release-Vorbereitung hotfix/* # Kritische Bugfixes

Git Flow ist ein etabliertes Branching-Modell mit zwei Hauptbranches (main, develop) und drei unterstützenden Branch-Typen. Es eignet sich besonders für Projekte mit regelmäßigen Releases.

Beispiele

# Feature-Branch erstellen

git checkout -b feature/login develop

# Feature in develop mergen

git checkout develop

git merge feature/login

# Release-Branch erstellen

git checkout -b release/1.2.0 develop

# Release in main und develop mergen

git checkout main

git merge release/1.2.0

git tag -a v1.2.0 -m "Release 1.2.0"

git checkout develop

git merge release/1.2.0

# Hotfix erstellen

git checkout -b hotfix/security-patch main

Tipp: Git Flow ist ideal für Projekte mit geplanten Releases und Versionierungen. Für kontinuierliche Bereitstellung (CD) sind andere Workflows oft besser geeignet.

GitHub Flow – Einfacher, kontinuierlicher Workflow

main · feature branches · Pull Requests

# Nur ein Hauptbranch main # Immer deploybar # Feature Branches (kurzlebig) feature/* # Neue Features # Workflow: Branch → PR → Merge → Deploy

GitHub Flow ist ein einfacher, kontinuierlicher Workflow mit einem einzigen Hauptbranch (main). Alle Änderungen werden über Feature-Branches und Pull Requests integriert.

Beispiele

# 1. Feature-Branch erstellen

git checkout -b feature/add-login

# 2. Änderungen committen

git add .

git commit -m "Benutzer-Login implementiert"

# 3. Branch pushen

git push -u origin feature/add-login

# 4. Pull Request auf GitHub erstellen

# → PR mit Review, CI/CD, Diskussion

# 5. Nach Merge: Branch löschen und deployen

git branch -d feature/add-login

git push origin --delete feature/add-login

# Automatisches Deployment nach main-Merge

# → GitHub Actions oder andere CI/CD Tools

Tipp: GitHub Flow ist ideal für Teams mit kontinuierlicher Bereitstellung. Der Hauptbranch sollte immer deploybar sein. Pull Requests sind der zentrale Punkt für Code-Reviews.

Trunk-Based Development – Kurzlebige Branches

trunk · short-lived branches · feature flags

# Single Trunk (main/trunk) main # Einziger Hauptbranch # Feature Branches (max. 1-2 Tage) feature/* # Kurzlebige Branches # Feature Flags für unfertige Features

Trunk-Based Development setzt auf einen einzigen Hauptbranch (trunk/main). Feature-Branches sind extrem kurzlebig (1-2 Tage) und werden häufig in den Trunk gemergt. Unfertige Features werden mit Feature Flags ausgeblendet.

Beispiele

# Feature-Branch (kurzlebig)

git checkout -b feature/short-lived

# Kleine Commits, regelmäßig pull/merge

git commit -m "WIP: neue Funktion"

git pull --rebase origin main # Rebase vor Merge

# Feature mit Feature Flag ausblenden

if (featureFlags.isEnabled('new-feature')) {

// Neue Funktionalität

}

# Nach Merge (kein Release-Branch nötig)

git checkout main

git merge feature/short-lived

# Feature Flag aktivieren, wenn fertig

# → Feature Flag auf true setzen

Tipp: Trunk-Based Development erfordert Disziplin: Branches sollten nicht länger als 1-2 Tage leben. Feature Flags sind essenziell, um unfertige Features im Trunk zu haben, ohne sie auszuliefern.

Feature Branches – Neue Funktionalitäten entwickeln

feature/ · branch · merge · rebase

# Feature-Branch erstellen git checkout -b feature/login develop # Work in Progress git add . git commit -m "Login implementiert" # Merge zurück (mit Rebase) git checkout develop git pull --rebase git merge feature/login

Feature Branches sind dedizierte Branches für die Entwicklung neuer Funktionen. Sie isolieren Änderungen und ermöglichen parallele Entwicklung, bevor sie in den Hauptbranch integriert werden.

Beispiele

# Feature-Branch mit Beschreibung

git checkout -b feature/payment-integration

# Mehrere Commits für das Feature

git add src/payment/*

git commit -m "Stripe SDK hinzugefügt"

git add tests/payment/*

git commit -m "Tests für Payment-Modul"

# Feature-Branch pushen

git push -u origin feature/payment-integration

# Branch mit Rebase aktualisieren

git checkout feature/payment-integration

git rebase develop

# Nach Merge: Branch löschen

git branch -d feature/payment-integration

git push origin --delete feature/payment-integration

Tipp: Nutzen Sie git rebase, um Ihren Feature-Branch mit dem aktuellen Hauptbranch zu aktualisieren – das erzeugt einen sauberen, linearen Verlauf und vermeidet Merge-Konflikte.

Release Branches – Release-Vorbereitung

release/ · version · tag · bugfixes

# Release-Branch erstellen git checkout -b release/1.2.0 develop # Letzte Bugfixes und Dokumentation git commit -m "Version 1.2.0 vorbereitet" # In main mergen und taggen git checkout main git merge release/1.2.0 git tag -a v1.2.0 -m "Version 1.2.0"

Release Branches dienen der Vorbereitung eines Releases. Sie ermöglichen letzte Bugfixes, Dokumentationsänderungen und die Anpassung von Versionierungsinformationen, bevor der Code in den Hauptbranch gemergt wird.

Beispiele

# Release-Branch erstellen

git checkout -b release/2.0.0 develop

# Version in Dateien aktualisieren

echo "2.0.0" > VERSION

git add VERSION

git commit -m "Version auf 2.0.0 gesetzt"

# Letzte Bugfixes

git commit -m "Dokumentation für Release aktualisiert"

# In main mergen

git checkout main

git merge release/2.0.0

git tag -a v2.0.0 -m "Release 2.0.0"

# Änderungen zurück in develop

git checkout develop

git merge release/2.0.0

# Release-Branch löschen

git branch -d release/2.0.0

Tipp: Release-Branches werden in Git Flow verwendet. Sie ermöglichen es, die Entwicklung am develop-Branch fortzusetzen, während das Release finalisiert wird.

Hotfixes – Schnelle Bugfixes in Produktion

hotfix/ · main · develop · tag

# Hotfix-Branch von main git checkout -b hotfix/critical-bug main # Bugfix committen git commit -m "Kritischer Bug gefixt" # In main mergen git checkout main git merge hotfix/critical-bug git tag v1.0.1 # Auch in develop mergen git checkout develop git merge hotfix/critical-bug

Hotfixes werden für kritische Bugfixes in der Produktion verwendet. Sie werden direkt vom main-Branch abgezweigt und nach dem Fix sowohl in main als auch in develop gemergt.

Beispiele

# Hotfix-Branch von main

git checkout -b hotfix/security-patch main

# Fix implementieren

git add src/security/*

git commit -m "Sicherheitslücke in Auth geschlossen"

# In main mergen (sofort deployen)

git checkout main

git merge hotfix/security-patch

git tag -a v1.0.1 -m "Sicherheits-Hotfix"

# Auch in develop mergen (damit der Fix nicht verloren geht)

git checkout develop

git merge hotfix/security-patch

# Branch löschen

git branch -d hotfix/security-patch

⚠️ Wichtig: Hotfixes sollten nur für kritische Fehler verwendet werden, die keine Zeit für einen normalen Release-Prozess lassen. Der Fix muss sowohl in main als auch in develop gemergt werden.

Git Workflows im Vergleich

Git Flow Klassisches Modell mit main, develop, release
Für geplante Releases

GitHub Flow Einfacher Workflow mit main + PRs
Für kontinuierliche Bereitstellung

Trunk-Based Ein Hauptbranch + kurze Feature-Branches
Für hohe Deployment-Frequenz

Feature Parallele Entwicklung neuer Features
+ branch, - branch

Release Release-Vorbereitung und Bugfixes
Nur in Git Flow

Hotfix Schnelle Fixes für Produktion
Von main abgezweigt

Quick Summary

Git Flow

Klassisches Branching

GitHub Flow

PR + main

Trunk-Based

Ein Branch + Flags

feature/*

Neue Features

release/*

Release-Vorbereitung

hotfix/*

Kritische Fixes

git checkout -b feature/new · git merge --no-ff feature/new · git tag v1.0.0