Git Workflows
Feature Branch, Gitflow und Trunk-based Development im Vergleich.
title: "Git Workflows" slug: "git-workflows" category: "DevOps" description: "Feature Branch, Gitflow und Trunk-based Development im Vergleich – wann welcher Workflow sinnvoll ist." tags: ["Git", "Branching", "CI/CD", "Trunk-Based", "Pull Request"] navigation_path: "/tiles/git-workflows"
Git Workflows
Ein Git Workflow definiert, wie ein Team Branches nutzt, Code reviewed und Features integriert. Die Wahl des richtigen Workflows beeinflusst die Deploymentfrequenz, die Code-Qualität und wie gut Teams skalieren können.
Jeder Workflow dreht sich um die gleiche Frage: Wann und wie landet Code auf dem main-Branch? Die Antwort bestimmt, wie schnell und wie sicher du deployen kannst.
Die drei gängigsten Workflows
Feature Branch Workflow
Jedes Feature bekommt einen eigenen Branch. Über einen Pull Request wird der Code reviewed und erst danach in main gemergt. Einfach, weit verbreitet, gut für kleine bis mittlere Teams.
Gitflow
Strukturierter Ansatz mit festen Branches: main, develop, feature/*, release/*, hotfix/*. Bietet viel Kontrolle, aber auch deutlich mehr Overhead. Sinnvoll bei versionierten Software-Releases.
Trunk-based Development
Alle Entwickler committen direkt (oder über kurzlebige Branches) auf main. Feature Flags verstecken unfertige Features. Voraussetzung für echtes Continuous Deployment.
Branching-Konventionen
Konsistente Branch-Namen machen den Commit-Graph lesbar und erlauben CI/CD-Pipelines, automatisch zu reagieren:
Namensschema
feature/user-authentication
fix/login-redirect-loop
chore/update-dependencies
release/v2.4.0
hotfix/null-pointer-checkout
Commit Messages (Conventional Commits)
feat: add OAuth2 login
fix: correct redirect after logout
docs: update README with setup steps
chore: bump next to 15.3
refactor: extract AuthProvider
Pull Requests richtig nutzen
Ein guter Pull Request ist klein, fokussiert und gut beschrieben. Faustregel: Ein PR = eine Änderung. Das erleichtert das Review und macht git bisect bei Bugs zum echten Werkzeug.
- Branch ist aktuell mit
main(kein Merge-Konflikt) - CI ist grün
- Eigenes Review gemacht – offensichtliche Fehler selbst gefunden
- Beschreibung erklärt das Warum, nicht nur das Was
- Screenshots bei UI-Änderungen hinzugefügt
Merge-Strategien
Ein Workflow ist erst vollständig, wenn klar ist, wie der Code in den Hauptbranch gelangt. Die Wahl der Strategie beeinflusst direkt, wie lesbar die Git-Historie bleibt.
Merge Commit
Erstellt einen eigenen Merge-Commit, der beide Historien verknüpft. Die vollständige Branch-Historie bleibt erhalten – gut sichtbar bei Gitflow, wo das Zusammenführen eines Features ein Ereignis ist.
Squash & Merge
Alle Commits eines Pull Requests werden zu einem einzigen, sauberen Commit zusammengefasst. Ideal für Feature Branches: Die Arbeit landet atomar auf main, ohne WIP-Commits wie „typo fix" oder „try again".
Rebase & Merge
Die Feature-Commits werden an die Spitze von main gesetzt – kein extra Merge-Commit, linear lesbarer Graph. Erfordert saubere, aussagekräftige Einzelcommits im Branch.
Hotfix-Handling
Was passiert, wenn die Produktion brennt? Ein robuster Workflow definiert für genau diesen Fall einen Ausnahmeprozess.
Gitflow Hotfix
Ein hotfix/-Branch zweigt direkt von main ab, wird schnell gefixt und fließt in beide Branches zurück – main und develop. So bleibt auch der Entwicklungsstand synchron.
git checkout -b hotfix/payment-null-crash main
# fix, commit
git checkout main && git merge --no-ff hotfix/...
git checkout develop && git merge --no-ff hotfix/...
git branch -d hotfix/payment-null-crash
Trunk-based „Roll Forward
Im Trunk-based Development wird der Fix direkt auf main committed – kein separater Branch nötig. Wenn ein Feature Flag den Bug verursacht hat, wird es sofort deaktiviert. Der nächste Deploy enthält den Fix.
Automatisierung & Git Hooks
Workflows funktionieren am besten, wenn sie durch Tooling erzwungen werden – nicht durch Disziplin allein.
Pre-Commit Hooks (Husky)
Husky führt vor jedem git commit lokale Checks aus: Linter, Formatter, Typen-Check. Fehler werden sofort gemeldet, bevor schlechter Code überhaupt ins Repository gelangt.
// package.json
"lint-staged": {
"*.{ts,tsx}": ["eslint --fix", "prettier --write"]
}
Branch Protection Rules
Im GitHub-Repository-Settings: direkte Pushes auf main verbieten, CI muss grün sein, mindestens ein Approval erforderlich. Der Workflow wird so strukturell erzwungen – kein Versehen möglich.
Release-Management & Tagging
Wie markiert ihr fertige Versionen und triggert Deployments?
v MAJOR.MINOR.PATCH – MAJOR bei Breaking Changes, MINOR bei neuen Features (abwärtskompatibel), PATCH bei Bugfixes. Beispiel: v2.4.1. Deployment-Pipelines können auf neue Tags reagieren und automatisch ein Release auslösen.
Git Tag setzen
git tag -a v2.4.0 -m "Release 2.4.0"
git push origin v2.4.0
Tags sind unveränderliche Markierungen im Commit-Graphen – ideal als Referenz für CI/CD.
Changelog automatisieren
Mit Conventional Commits als Basis können Tools wie release-please oder semantic-release automatisch Changelogs generieren und die Versionsnummer hochzählen – ohne manuellen Aufwand.
Stale Branches aufräumen
Ein oft unterschätztes Hygiene-Thema: Repositories mit Dutzenden veralteter Branches sind schwer navigierbar und erzeugen False Confidence ("wurde das schon gemergt?").
Die Regel
Nach einem erfolgreichen Merge wird der Feature-Branch sofort gelöscht. GitHub bietet dafür die Option „Automatically delete head branches" in den Repository-Settings – ein Klick, kein Nachdenken.
Aufräumen alter Branches
# Alle bereits gemergten Branches anzeigen
git branch --merged main
# Remote-Branches älter als 30 Tage finden
git for-each-ref --sort=committerdate refs/remotes \
--format='%(refname:short) %(committerdate:relative)'
Empfehlung
Für die meisten modernen Web-Teams ist Trunk-based Development mit Feature Flags das Ziel – aber der Feature Branch Workflow ist der pragmatische Einstieg. Gitflow lohnt sich fast nur noch bei klassischer Release-Versionierung (z. B. SDKs oder Desktop-Software).