Git Branching Strategie einfach erklärt

Git Branching Strategie einfach erklärt

  • Beitrags-Autor:
  • Beitrags-Kategorie:Java

Warum braucht man überhaupt eine Branching Strategie?

Viele Einsteiger arbeiten anfangs einfach direkt auf main. Für ganz kleine Experimente geht das vielleicht noch. Sobald ein Projekt aber etwas größer wird oder mehrere Änderungen parallel laufen, wird das ohne eine Git Branching Strategie schnell unübersichtlich.

Eine Branching-Strategie hilft dir dabei:

  • Änderungen sauber zu trennen
  • neue Features kontrolliert zu entwickeln
  • Bugs gezielt zu beheben
  • Releases vorzubereiten
  • den stabilen Stand deines Projekts zu schützen

Was ist ein Branch überhaupt?

Ein Branch ist ein Entwicklungszweig in Git. Damit kannst du an etwas arbeiten, ohne den Hauptstand direkt kaputtzumachen.

Zum Beispiel:

  • neues Feature bauen
  • Fehler beheben
  • Release vorbereiten

Wenn du Branches noch nicht sauber eingeordnet hast, passt zuerst oder parallel der Artikel Git und GitHub einfach erklärt.

Warum nicht einfach immer auf main arbeiten?

Direkt auf main zu arbeiten ist riskant. Typische Probleme:

  • unfertige Änderungen landen im Hauptstand
  • Bugs und neue Features vermischen sich
  • Releases sind schwerer nachvollziehbar
  • parallele Arbeit wird chaotisch

main sollte im Idealfall immer ein stabiler Branch sein.

Ein einfaches Modell für kleine bis mittlere Projekte

Ein sehr brauchbares Modell ist dieses:

  • main
  • dev
  • feature/...
  • bugfix/...
  • release/vx.y.z

Das lehnt sich an Gitflow an, bleibt aber verständlich genug für Einsteiger.

Was macht main?

main ist dein stabiler Hauptbranch.

Auf main sollte nur landen, was wirklich in einem brauchbaren, releasefähigen Zustand ist.

Man kann sagen:

  • main zeigt den sauberen Hauptstand
  • main ist nicht der Ort für unfertige Zwischenarbeit

Was macht dev?

dev ist dein Integrations-Branch für laufende Entwicklung. Dort laufen neue Änderungen zusammen, bevor sie später in main übernommen werden.

Das ist praktisch, weil:

  • main stabil bleibt
  • neue Features nicht direkt auf den Hauptstand knallen
  • mehrere Änderungen besser koordiniert werden können

Was sind feature-Branches?

Ein feature-Branch ist für neue Funktionen da.

Beispiele:

  • feature/login-form
  • feature/user-profile
  • feature/rest-client

Ein typischer Ablauf: 1. von dev abzweigen 2. Feature bauen 3. testen 4. zurück in dev mergen

Beispiel:

git checkout dev
git checkout -b feature/login-form

Was sind bugfix-Branches?

Ein bugfix-Branch ist für Fehlerbehebungen da.

Beispiele:

  • bugfix/nullpointer-login
  • bugfix/maven-build-fehler

Auch diese Branches gehen in diesem Modell meistens von dev aus und später zurück nach dev.

Beispiel:

git checkout dev
git checkout -b bugfix/nullpointer-login

Was sind release-Branches?

Ein release-Branch ist dafür da, eine neue Version gezielt vorzubereiten.

Beispiele:

  • release/v1.0.0
  • release/v1.1.0

Ein Release-Branch ist nützlich, wenn du:

  • letzte Tests machst
  • kleine letzte Fixes einbaust
  • eine Version klar abgrenzen willst
  • einen nachvollziehbaren Weg Richtung produktivem Stand brauchst

Typischer Ablauf:

  • release/v1.0.0 von dev erstellen
  • letzte Korrekturen dort machen
  • danach nach main mergen
  • und meist auch zurück nach dev

Wie hängt das mit Semantic Versioning zusammen?

Semantic Versioning bedeutet normalerweise ein Versionsschema wie:

  • 1.0.0
  • 1.1.0
  • 1.1.1

Die Logik dahinter ist grob:

  • Major: große Änderungen oder Brüche
  • Minor: neue Funktionen ohne großen Bruch
  • Patch: kleine Fehlerbehebungen

Beispiele:

  • 1.0.0 -> erste stabile Version
  • 1.1.0 -> neues Feature dazu
  • 1.1.1 -> Bugfix-Release

Darum passt ein Release-Branch wie release/v1.0.0 gut zu diesem Modell.

Ein realistischer Ablauf im Projekt

Stell dir vor, du baust ein Java-Projekt und willst ein Login-Feature einführen.

Dann könnte der Ablauf so aussehen:

1. stabiler Stand liegt auf main 2. laufende Entwicklung liegt auf dev 3. du erstellst feature/login 4. Feature wird fertig und in dev gemerged 5. weitere Änderungen kommen dazu 6. du erstellst release/v1.0.0 7. letzte Tests und kleine Fixes passieren dort 8. Release wird nach main gemerged

Das ist deutlich sauberer, als alles direkt auf main zu kippen.

Einfache Git-Befehle für diesen Workflow

Einen neuen Feature-Branch anlegen:

git checkout dev
git checkout -b feature/neues-feature

Einen Bugfix-Branch anlegen:

git checkout dev
git checkout -b bugfix/fehlername

Einen Release-Branch anlegen:

git checkout dev
git checkout -b release/v1.0.0

Ist das schon Gitflow?

Es ist stark daran angelehnt, aber in einer vereinfachten Form. Klassisches Gitflow ist etwas formaler und teilweise für kleine Projekte schon zu schwergewichtig. Für viele Lern-, Solo- oder kleinere Teamprojekte reicht ein reduziertes Modell völlig aus:

  • main
  • dev
  • feature
  • bugfix
  • release

Das ist klar, nachvollziehbar und praxistauglich.

Typische Fehler bei Branching-Strategien

Zu viele Regeln für ein kleines Projekt

Wenn dein Projekt winzig ist, brauchst du kein Monster-Prozessmodell.

Gar keine Regeln

Das andere Extrem ist genauso schlecht. Dann weiß niemand, wo was hingehört.

Direkt auf main entwickeln

Das ist auf Dauer fast immer unnötig riskant.

Branches schlecht benennen

test123 oder neu helfen niemandem.

Besser:

  • feature/login
  • bugfix/maven-build
  • release/v1.0.0

Für wen ist dieses Modell sinnvoll?

Dieses Modell passt gut für:

  • Lernprojekte mit Struktur
  • Portfolio-Projekte
  • Solo-Projekte mit etwas Disziplin
  • kleine Teams
  • Java- und Spring-Boot-Projekte mit sauberem Workflow

Wo kommt CI/CD ins Spiel?

CI/CD wird besonders spannend, wenn Branches sauber strukturiert sind.

Dann kannst du zum Beispiel festlegen:

  • auf feature/* laufen Tests
  • auf dev laufen Build und Integrationstests
  • auf release/* laufen Release-Checks
  • auf main läuft der produktive oder stabile Workflow

Darum hängt eine gute Branching-Strategie oft eng mit CI/CD zusammen.

Fazit

Eine Branching-Strategie bringt Ordnung in deine Entwicklung.

Für viele Projekte ist dieses Modell ein guter Start:

  • main für stabil
  • dev für laufende Entwicklung
  • feature/* für neue Funktionen
  • bugfix/* für Fehlerbehebungen
  • release/vx.y.z für Releases

Wenn du das mit sauber benannten Branches und Semantic Versioning kombinierst, hast du schon ein sehr brauchbares System.

Nächster Schritt

Nach diesem Artikel passen diese Themen gut: