Git Branching Strategien: Der richtige Workflow für Ihr Team

Die richtige Branching-Strategie ist entscheidend für effiziente Teamarbeit. Dieser Guide vergleicht die gängigsten Strategien und hilft bei der Auswahl.

Warum Branching-Strategien?

• Parallele Entwicklung ermöglichen
• Stabile Produktion schützen
• Code-Reviews vereinfachen
• Releases kontrollieren

1. Git Flow

Klassische Strategie für Release-basierte Projekte.

Branches

Workflow

# Neues Feature starten
git checkout develop
git checkout -b feature/user-login

# Feature entwickeln und committen
git add .
git commit -m "Add login form"

# Feature abschließen
git checkout develop
git merge --no-ff feature/user-login
git branch -d feature/user-login

# Release vorbereiten
git checkout -b release/1.0.0
# Bugfixes, Version-Bumps
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Version 1.0.0"
git checkout develop
git merge --no-ff release/1.0.0

# Hotfix
git checkout main
git checkout -b hotfix/critical-bug
# Fix committen
git checkout main
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1
git checkout develop
git merge --no-ff hotfix/critical-bug

Vorteile & Nachteile

✅ Klare Struktur, gute Versionierung, parallele Releases

❌ Komplex, viele Branches, langsame Integration

2. GitHub Flow

Einfacher Workflow für kontinuierliches Deployment.

Regeln

1. main ist immer deploybar
2. Für jede Änderung ein Branch von main
3. Pull Request öffnen
4. Review und Diskussion
5. Deploy und testen
6. In main mergen

Workflow

# Branch erstellen
git checkout main
git pull
git checkout -b add-search-feature

# Entwickeln und committen
git add .
git commit -m "Add search functionality"
git push -u origin add-search-feature

# Pull Request auf GitHub erstellen
# → Review → Merge → Delete Branch

# Lokal aufräumen
git checkout main
git pull
git branch -d add-search-feature

Vorteile & Nachteile

✅ Einfach, schnelle Integration, ideal für CD

❌ Keine expliziten Releases, main muss stabil bleiben

3. Trunk-Based Development

Alle arbeiten auf main mit kurzen Feature-Branches.

Regeln

• Branches leben max. 1-2 Tage
• Kleine, häufige Commits
• Feature Flags für unfertige Features
• Starke CI/CD Pipeline erforderlich

Workflow

# Kurzer Branch (1 Tag max)
git checkout main
git pull
git checkout -b quick-fix

# Kleine Änderung
git commit -m "Fix typo in header"
git push origin quick-fix

# Sofort mergen (nach Review)
git checkout main
git merge quick-fix
git push
git branch -d quick-fix

# Oder direkt auf main (bei kleinen Änderungen)
git checkout main
git commit -m "Update config"
git push

Feature Flags

// Unfertiges Feature verstecken
if (featureFlags.newDashboard) {
  return <NewDashboard />;
}
return <OldDashboard />;

Vorteile & Nachteile

✅ Schnellste Integration, wenig Merge-Konflikte, Continuous Deployment

❌ Braucht starke Tests/CI, nicht für alle Teams geeignet

Welche Strategie wählen?

Branch-Namenskonventionen

# Feature
feature/user-authentication
feature/JIRA-123-add-login

# Bugfix
bugfix/login-error
fix/null-pointer-exception

# Hotfix (für Produktion)
hotfix/security-patch
hotfix/v1.2.1

# Release
release/1.0.0
release/2024-01

# Chore/Maintenance
chore/update-dependencies
docs/update-readme

Commit Message Konventionen

# Conventional Commits
feat: add user authentication
fix: resolve login timeout issue
docs: update API documentation
style: format code with prettier
refactor: simplify validation logic
test: add unit tests for auth
chore: update dependencies

# Mit Scope
feat(auth): add OAuth2 support
fix(api): handle null response

# Mit Breaking Change
feat!: change API response format

BREAKING CHANGE: The response now returns
an object instead of array.

Weitere Informationen

• 📖 Git Grundlagen
• 🚀 GitHub Actions CI/CD