Lukiluki
DEEN
Menu

Ambience

Language
DEEN
Workflows & Testing
GitTrunk-BasedRebaseCI/CD
🌐 English translation in progress – displaying original German guide.

Git Workflows – Branching, Rebase & Release-Strategien

Leitfaden für moderne Git-Workflows: Trunk-Based Development, Feature Branches und Gitflow im Vergleich mit interaktivem Terminal-Befehls-Generator.

LKLukas Kopischke
Last updated on

Freitagnachmittag, 16:30 Uhr: Ein kritischer Produktions-Bug muss sofort gepatcht werden. Doch der Entwicklungs-Branch enthält bereits halbfertige Änderungen aus drei verschiedenen Sprint-Aufgaben. Beim Versuch eines Merges eskalieren Konflikte in 28 Dateien, die CI wird rot und niemand traut sich, den Release-Knopf zu drücken. Unklare Branching-Strategien kosten Engineering-Teams mehr Produktivität als fehlerhafter Code.

Ein moderner Git-Workflow regelt verbindlich, wie Branches benannt, Änderungen gereviewt und Features in den Hauptzweig (main) integriert werden. Während Trunk-Based Development mit kurzlebigen Branches (< 24 Stunden) und Feature Flags maximale Deploymentfrequenz ermöglicht, bieten Feature-Branch- und Gitflow-Modelle strukturierte Kontrollschranken für versionierte Release-Zyklen.

Die goldene Regel

Code auf langlebigen Feature-Branches ist eine technische Verbindlichkeit: Je länger ein Zweig isoliert bleibt, desto höher fallen die Zinsen in Form schmerzhafter Merge-Konflikte aus.

Git Workflow & Command GeneratorLive Werkbank
Wähle deine Team-Struktur: Konfiguriere Branching-Modelle und generiere die exakten Bash-Befehle für saubere Commit-Historien.

Trunk-Based Development

Kurzlebige Feature-Branches, direkte Integration in main, unfertiger Code hinter Feature Flags.

Zyklus: < 1 Tag Branch-LebensdauerMerge: Squash & Merge
Commit-Graph Topologie:
main ●─────●─────────● (Release)
\ ↑ (Squash)
feat/fast ●─●┘
Bash / Zsh Kommandos
# 1. Neuesten Stand holen
git checkout main && git pull --rebase
# 2. Kurzlebigen Branch anlegen (max. 1 Tag alt)
git checkout -b feat/user-quickfix
# 3. Kleine, atomare Commits
git commit -am 'feat: implement small atomic unit'
# 4. Vor PR lokal mit main rebasen
git fetch origin && git rebase origin/main
# 5. In main integrieren (Squash & Merge via PR)
git push origin feat/user-quickfix

Die drei dominierenden Arbeitsmodelle

Trunk-Based Development

CI/CD Standard

Alle Entwickler integrieren Code mehrmals täglich direkt auf main (oder über ultrakurzlebige Branches). Unfertige Features werden über Feature Flags vor Endnutzern verborgen.

Feature Branch Workflow

PR-Standard

Jedes Ticket erhält einen eigenen Branch (feature/*). Ein Pull Request erzwingt Peer-Review und grüne CI-Pipelines, bevor der Code per Squash & Merge auf main landet.

Gitflow (Release Trains)

Versionierte Software

Feste Branches für Entwicklung (develop), Produktion (main), versionierte Releases (release/*) und Notfall-Patches (hotfix/*). Bietet maximale Kontrolle, erzeugt aber hohen Koordinationsaufwand.

Do's & Don'ts: Saubere Branching-Hygiene

Empfohlen (Best Practice)
  • Branches kurzlebig halten (unter 24–48 Stunden bis zum Merge)
  • Squash & Merge für Feature-Branches nutzen, um die main-Historie atomar zu halten
  • Lokale Feature-Branches vor dem PR via git pull --rebase mit main synchronisieren
  • Conventional Commits (feat:, fix:, chore:) für automatische Changelogs nutzen
Zu vermeiden (Anti-Pattern)
  • Langlebige Monster-Branches über mehrere Wochen ohne Rebase pflegen
  • Unfertige Zwischenstände wie „WIP", „fix typo", „asdf" unkomprimiert in main mergen
  • Merge-Commits zwischen zwei Feature-Branches kreuzen („Spaghetti-Graphen")
  • Stale Branches nach dem erfolgreichen Merge im Remote-Repository liegen lassen

Merge-Strategien im Detail

Wie Code in den Hauptbranch gelangt, bestimmt die Lesbarkeit der Versionshistorie bei Debugging und git bisect:

Squash & Merge

Empfohlen für PRs

Fasst alle Commits eines Feature-Branches zu einem einzigen zusammen. Beseitigt Rauschen und macht Revert-Vorgänge trivial.

Rebase & Fast-Forward

Lineare Historie

Setzt Commits an die Spitze des Ziel-Branches. Ergibt eine schnurgerade, saubere Git-Historie ohne künstliche Merge-Knoten.

Merge Commit (--no-ff)

Explizite Meilensteine

Erzeugt einen dedizierten Knotenpunkt. Nützlich bei Gitflow, um Release-Abschnitte im Commit-Graph visuell nachvollziehbar zu halten.

Automatisierung & Branch Protection

Zuverlässige Workflows basieren auf automatisierten Leitplanken statt menschlicher Selbstdisziplin:

Pre-Commit Hooks mit Husky

Lokale Filter

Verhindert, dass fehlerhafter Code überhaupt committed wird. Führt eslint --fix, prettier und TypeScript-Checks auf gestageten Dateien aus.

Branch Protection Rules

GitHub / GitLab

Direktes Pushen auf main blockieren. Verlangt mindestens ein Peer-Approval und erfolgreiche CI-Testläufe vor jedem Merge.

Synergie mit automatisiertem Testing

Ein schneller Branch-Zyklus funktioniert nur mit verlässlichen Regressionstests. Wie du Unit-, Integrations- und E2E-Tests optimal strukturierst, zeigt unser Leitfaden zu Frontend Testing.

Checkliste: Git-Workflows in der Praxis

  • Branch-Schutz aktiv: Direkte Pushes auf main sind in den Repository-Settings strikt verboten.
  • Lebensdauer begrenzt: Feature-Branches werden innerhalb von 48 Stunden per Pull Request gemergt.
  • Squash & Merge aktiviert: Lokale WIP-Commits werden beim Integrieren automatisch zusammengefasst.
  • Automatische Aufräumfunktion: Die Option „Automatically delete head branches“ ist in GitHub aktiviert.
  • Lineare Synchronisation: Vor dem Erstellen des PRs wird der Branch per git fetch && git rebase origin/main aktualisiert.