A praktischer Leitfodn zu Git-Branching-Strategien

De meisten Teams wählen ka Branching-Strategie - sie erben, wos die Gründer-Entwickler grod gmacht hom, und es verhärtet si, bevor wer fragt, ob's zur tatsächlichen Teamgröße und zum Release-Rhythmus passt. So kummt's, dass a Fünf-Leit-Startup an Prozess fahrt, der für a Hundert-Leit-Organisation mit Quartals-Releases gedacht woar, oda a Team, des täglich in Produktion liefert, no immer a permanente develop-Branch pflegt, von derer niemand mehr woaß, wofür sie do is. Die richtige Strategie hängt komplett davon ab, wia oft du deployst und wia vüle Sochn gleichzeitig laufn - ned davon, wöche des fanciest Diagramm hot.

Trunk-based Development

Alle committen auf main (oda auf sehr kurzlebige Branches, de innerhoib vom Tag gmerged wern), hinter Feature Flags, wenn die Orbeit no ned für Nutzer sichtbar sei soit.

git checkout main
git pull
git checkout -b add-export-button
# ... small, focused change ...
git push -u origin add-export-button
# open PR, merge same day, delete branch

Des funktioniert gut, wennst oft deployst - mehrmals am Tag, oda zumindest täglich - und solide CI und Feature Flagging hast. Der ganze Sinn is, dass Branches nie long genug leben, um weit von main wegzudriften, drum bleiben Merge-Konflikte klan und Integrationsprobleme tauchen sofort auf, statt sich anzuhäufen. Ohne Feature Flags fallt's auseinander: Wenn aus "klane, fokussierte Änderung" still und leise "halbfertiges Feature, des Nutzer sehen" wird, host grod a langlebige Branch neu erfunden, nur mit mehr Schritten.

Git Flow

Das klassische Schwergewichts-Modell: a permanente develop-Branch für die Integration, feature/-Branches von develop, release/-Branches zum Stabilisiern ana Version, und main reserviert für des, wos wirklich in Produktion is, mit hotfix/*-Branches, um sie direkt zu patchen.

git checkout develop
git checkout -b feature/user-avatars
# ... work, potentially over days or weeks ...
git checkout develop
git merge --no-ff feature/user-avatars

# when develop is ready to ship
git checkout -b release/2.4.0 develop
# stabilization fixes go here, then:
git checkout main
git merge --no-ff release/2.4.0
git tag v2.4.0
git checkout develop
git merge --no-ff release/2.4.0

Des macht Sinn, wennst wirklich nach ana Terminplanung auslieferst - a Desktop-App mit Quartals-Releases, a Embedded-Firmware-Update, olles, wo "wos grod in main is" und "wos wir aktiv aufbaun" wochenlang unterschiedliche Sochn sei miassn. Für a Web-App mit kontinuierlichem Deployment bringt die develop/release-Trennung Zeremonie ohne entsprechenden Nutzen - es gibt ka eigenen "Release"-Moment, auf den ma hin stabilisiern müsst.

GitHub Flow

Der Mittelweg: ka develop, koane release-Branches. main is imma deploybar, Feature-Branches zweigen direkt davon ab, und s'Mergen nach main löst an Deploy aus.

git checkout main
git pull
git checkout -b fix-pagination-off-by-one
# ... work ...
git push -u origin fix-pagination-off-by-one
# open PR, get review, merge — CI deploys main automatically

Des is der Standard, zu dem viele Teams greifen soitn: Es hot Git Flows Klarheit (a echte Branch pro Arbeitseinheit, per PR reviewt) ohne die Multi-Branch-Buchhaltung, und es passt natürlich zu Continuous Deployment, weil's genau a Branch gibt, de zählt. Der Kompromiss gegenüber Trunk-based ist die Branch-Lebensdauer - a Feature-Branch kann do a poar Tage Review und Iteration lebn, was a bissl Merge-Drift wieda einführt, den reines Trunk-based vermeidet, aber dafür kriagst an echten Review-Checkpoint, bevor Code main erreicht.

Eine auswählen

• Trunk-based: Mehrmals am Tag deployn, Feature-Flag-Infrastruktur vorhanden, Team diszipliniert bei kleinen Commits.
• GitHub Flow: Mindestens a poar Moi in da Woch deployn, PR-Review ois Gate wollen, koane parallelen Release-Linien brauchen.
• Git Flow: Diskrete, nummerierte Releases mit echter Zeit dazwischen ausliefern, a ältere Version patchen müssen, während ma die nächste entwickelt.

Teamgröße zählt weniger, ois Leit annehmen. A Solo-Entwickler profitiert von GitHub Flows PR-pro-Änderung-Disziplin ois Dokumentation der Absicht, a wenn niemand sonst reviewt. A Zwanzig-Leit-Team kann Trunk-based erfolgreich fahrn, wenn die Investition in CI und Flagging do is - die Einschränkung is Prozessreife, ned Kopfzahl.

Namenskonventionen, de wirklich hüfn

Egal, wöche Strategie du wählst: a konsistentes Branch-Präfix mocht git branch -a und CI-Dashboards auf an Blick überschaubar:

feature/short-description
fix/short-description
chore/short-description
hotfix/short-description

Verzicht drauf, Ticketnummern ois einzigen Identifier einzubettn (JIRA-4521) - sechs Monate später woaß niemand mehr, wos des woar, ohne nachzuschaun, während fix/export-csv-encoding dir's sofort sagt. Wenn dein Tracker für Automatisierung wichtig is, setz die Ticket-ID hinter die Beschreibung, ned anstatt: fix/export-csv-encoding-JIRA-4521.

Die oane Gewohnheit, die mehr zählt ois die Strategie

Egal, wöches Modell du nutzt: Merge oda rebase von da Basis-Branch, bevor du a PR aufmachst, ned erst, wenn Review-Kommentare auf an mittlerweile veralteten Diff einprasseln.

git checkout feature/add-export-button
git fetch origin
git rebase origin/main
# resolve conflicts here, while the change is fresh in your head
git push --force-with-lease

--force-with-lease statt --force is hier wichtig - es weigert si, die Remote-Branch zu überschreiben, wenn wer ondrer seit deim letztn Fetch draufgepusht hot, was plain --force still und leise plattmochn würd.

Fazit

Es gibt ka universell richtige Branching-Strategie - es gibt nur die, de zu deiner tatsächlichen Deploy-Frequenz passt. Trunk-based und GitHub Flow nehmen beide an, dass main fost imma auslieferbar is, und unterscheiden si hauptsächlich darin, wia vül Review-Reibung vor am Merge sitzt; Git Flow nimmt an, dass des ned so is, und zahlt dafür mit mehr Branches zum Verfolgen. Wähl nach da Häufigkeit, mit der du auslieferst, ned danach, wöches Diagramm im Wiki am raffiniertesten ausschaut.