Branching und Merging

In dieser Lerneinheit meisterst du die wichtigen Konzepte des Branching und Merging in der Versionsverwaltung, die dir paralleles Arbeiten an verschiedenen Features ermöglichen. Du lernst, wie du Branches erstellst, zwischen ihnen wechselst und sie später wieder zusammenführst - Kernkompetenzen für die professionelle Softwareentwicklung im Team. Diese Fähigkeiten wendest du direkt in der Praxis an, um Code-Änderungen sicher und strukturiert zu verwalten.

Einführung

Du arbeitest an einem neuen Feature für eure App. Gleichzeitig fixt ein Teammitglied einen kritischen Bug im Produktionscode. Ein anderer entwickelt parallel eine weitere Funktion.

Chaos ohne Branches vs. parallele Entwicklung mit Branching — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Wie kann euer Team gleichzeitig an verschiedenen Features arbeiten, ohne sich gegenseitig zu blockieren oder den funktionierenden Code zu gefährden?

Die Antwort liegt in Branching und Merging, zwei zentralen Konzepten der Versionsverwaltung. Sie ermöglichen paralleles Arbeiten, isolierte Entwicklung und kontrolliertes Zusammenführen von Änderungen.

In dieser Lerneinheit lernst du, wie du Branches erstellst, zwischen ihnen wechselst, Änderungen zusammenführst und dabei auftretende Konflikte souverän löst.

Lernziele

Nach dieser Lerneinheit kannst du:

• Branches mit modernen Git-Befehlen erstellen, wechseln und löschen
• Merges durchführen und dabei verschiedene Strategien anwenden
• Merge-Konflikte systematisch erkennen und auflösen
• Branching-Workflows wie Feature-Branch und Git-Flow in der Praxis einsetzen
• Pull Requests als Mechanismus für Code-Integration verstehen

Branching in der Praxis

In der Lerneinheit Grundlegende Konzepte und Begriffe hast du gelernt, dass ein Branch ein Zeiger auf einen bestimmten Commit ist. Branches ermöglichen parallele Entwicklungslinien, ohne den Hauptcode zu beeinflussen.

Jetzt lernst du die praktische Arbeit: Wie du Branches erstellst, zwischen ihnen wechselst und sie wieder löschst. Wir nutzen dabei die modernen Git-Befehle git switch und git branch, die seit Git 2.23 (2019) die veralteten git checkout-Varianten ersetzen.

Branch erstellen und wechseln

Branch erstellen

Um einen neuen Branch zu erstellen, nutzt du:

git branch <branch-name>

Dieser Befehl erstellt den Branch, wechselt aber nicht automatisch dorthin.

Beispiel:

git branch feature/user-auth

Zu einem Branch wechseln

Um zu einem anderen Branch zu wechseln, nutzt du den modernen Befehl git switch:

git switch <branch-name>

Beispiel:

git switch feature/user-auth

Nach diesem Befehl arbeitest du im feature/user-auth Branch. Alle Commits werden diesem Branch zugeordnet.

Branch erstellen UND wechseln (in einem Schritt)

Die schnellere Variante kombiniert beides:

git switch -c <branch-name>

Beispiel:

git switch -c feature/payment-system

Dieser Befehl erstellt feature/payment-system und wechselt direkt dorthin.

Branch-Übersicht und Löschen

Alle Branches anzeigen

Um eine Übersicht aller lokalen Branches zu erhalten:

git branch

Der Branch, in dem du dich gerade befindest, wird mit einem Sternchen (*) markiert.

Beispiel-Ausgabe:

  feature/user-auth
* main
  feature/payment-system

Du befindest dich im main Branch.

Branch löschen

Wenn ein Branch nicht mehr benötigt wird (z. B. nach dem Merge), kannst du ihn löschen:

git branch -d <branch-name>

Beispiel:

git branch -d feature/user-auth

Git prüft automatisch, ob der Branch gemerged wurde. Falls nicht, musst du -D (Force-Delete) verwenden.

Tipp: Halte dein Repository sauber, indem du gemergede Feature-Branches regelmäßig löschst.

Merging durchführen

Merging ist der Prozess, bei dem Änderungen aus einem Branch in einen anderen überführt werden. Das ist notwendig, wenn ein Feature fertig ist und in den Hauptbranch (meist main) integriert werden soll.

Wann wird ein Merge benötigt?

• Feature-Branch ist fertig und soll in main integriert werden
• Aktuelle Änderungen aus main sollen in deinen Feature-Branch einfließen

Merge durchführen

Schritt 1: Wechsle zum Zielbranch (wohin du mergen möchtest)

git switch main

Schritt 2: Hole den aktuellsten Stand

git pull origin main

Schritt 3: Merge den Feature-Branch

git merge feature/user-auth

Git führt automatisch den Merge durch. Bei Erfolg siehst du eine Bestätigung.

Merge-Konflikte erkennen

Nicht jeder Merge verläuft reibungslos. Wenn beide Branches dieselben Zeilen geändert haben, entsteht ein Merge-Konflikt. Git kann diesen nicht automatisch auflösen.

Wie erkennst du einen Konflikt?

Nach git merge feature-branch siehst du eine Meldung wie:

Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.

Betroffene Dateien finden

git status

Dateien mit Konflikten werden als “unmerged” markiert.

Konflikt-Markierungen im Code

Git kennzeichnet die konfliktbehafteten Stellen:

<<<<<<< HEAD
Deine Änderungen (aktueller Branch)
=======
Änderungen aus dem Feature-Branch
>>>>>>> feature-branch

HEAD: Deine Änderungen feature-branch: Änderungen aus dem anderen Branch =======: Trennung

Merge-Konflikte auflösen

Schritt-für-Schritt-Anleitung

Schritt 1: Öffne die betroffene Datei in einem Editor

Schritt 2: Entscheide für jeden Konflikt:

• Behalte die Änderungen aus HEAD (deine Änderungen)
• Behalte die Änderungen aus feature-branch
• Kombiniere beide Änderungen
• Schreibe etwas komplett Neues

Schritt 3: Entferne alle Konflikt-Markierungen (<<<<<<<, =======, >>>>>>>)

Schritt 4: Speichere die Datei

Schritt 5: Füge sie zum Staging-Bereich hinzu:

git add <dateiname>

Schritt 6: Schließe den Merge ab:

git commit

Git öffnet einen Editor mit einer vorgefertigten Commit-Message. Speichere und schließe sie.

Best Practice: Kommuniziere mit Teammitgliedern bei komplexen Konflikten. Sie haben oft Kontext, der dir beim Lösen hilft.

Merge-Strategien im Detail

Git bietet verschiedene Merge-Strategien, um unterschiedliche Situationen zu handhaben.

Strategie	Beschreibung	Wann nutzen
Fast-Forward	Git verschiebt nur den Zeiger des Zielbranches. Keine neue Commit-Historie.	Wenn keine neuen Commits im Zielbranch existieren. Saubere, lineare Historie.
Recursive	Standardstrategie für Merges mit gemeinsamen Vorgängern. Erstellt einen Merge-Commit.	Bei parallelen Entwicklungslinien mit gemeinsamer Historie.
Ours	Behält nur Änderungen aus dem aktuellen Branch.	Wenn du den Feature-Branch verwerfen willst, aber den Merge dokumentieren möchtest.
Theirs	Behält nur Änderungen aus dem zu mergenden Branch.	Selten verwendet.

Fast-Forward Merge

Wenn main keine neuen Commits hat, seit der Feature-Branch erstellt wurde:

git merge feature-branch  # Fast-Forward automatisch

Recursive Merge

Wenn beide Branches Commits haben, erstellt Git einen Merge-Commit:

git merge feature-branch  # Erstellt Merge-Commit

⏳ Lädt Dataview-Inhalt...

Branching-Workflows: Überblick

In der professionellen Softwareentwicklung nutzen Teams strukturierte Branching-Workflows, um parallele Arbeit zu koordinieren. Diese Workflows definieren, wie Branches erstellt, genutzt und zusammengeführt werden.

Warum sind Workflows wichtig?

• Klare Regeln für Branch-Erstellung und -Benennung
• Einheitliche Prozesse für Code-Integration
• Vermeidung von Chaos bei vielen Entwicklern
• Saubere, nachvollziehbare Git-Historie

Die gängigsten Workflows:

• Feature-Branch Workflow: Für jedes Feature ein eigener Branch
• Git-Flow: Strukturierter Workflow mit festen Branch-Typen
• Forking Workflow: Jeder Entwickler arbeitet in seiner eigenen Repository-Kopie

Schauen wir uns diese im Detail an.

Feature-Branch Workflow

Beim Feature-Branch Workflow erstellt du für jedes Feature einen separaten Branch vom Hauptbranch (main). Dies isoliert die Entwicklung und ermöglicht parallele Arbeit.

Workflow-Schritte

1. Branch für Feature erstellen:

git switch -c feature/user-profile

2. Feature entwickeln und committen:

git add .
git commit -m "Add user profile page"

3. Feature fertigstellen und mergen:

git switch main
git merge feature/user-profile

4. Feature-Branch löschen:

git branch -d feature/user-profile

Vorteile

• Einfach zu verstehen und umzusetzen
• Hauptbranch bleibt stabil
• Features können isoliert getestet werden
• Gut für kleine bis mittlere Teams

Git-Flow: Die Struktur

Git-Flow ist ein strukturiertes Branching-Modell mit festen Branch-Typen für verschiedene Entwicklungsphasen. Es nutzt mehrere parallel laufende Branches.

Branch-Typen

Branch-Typ	Zweck	Langlebig?
main	Produktionscode, immer stabil	✅ Ja
develop	Integration Branch für Features	✅ Ja
feature/*	Feature-Entwicklung	❌ Nein (kurzlebig)
release/*	Release-Vorbereitung	❌ Nein (kurzlebig)
hotfix/*	Dringende Bugfixes für Production	❌ Nein (kurzlebig)

Grundprinzip

• Features werden in separaten Branches entwickelt
• Integration erfolgt über den develop Branch
• Releases werden über release/* Branches vorbereitet
• Hotfixes gehen direkt in main und develop

Wichtig: Git-Flow ist mächtig, aber komplex. Für Best Practices und Entscheidungskriterien, wann du es nutzen solltest, siehe Lerneinheit Best Practices und Troubleshooting.

Forking Workflow

Im Forking Workflow forkt jeder Entwickler das zentrale Repository und arbeitet in seiner eigenen Kopie. Dieses Modell wird häufig in Open-Source-Projekten genutzt.

Ablauf

1. Repository forken (auf GitHub/GitLab)

2. Fork lokal clonen:

git clone https://github.com/mein-user/projekt.git

3. In Fork arbeiten:

git switch -c feature/new-feature
# ... Änderungen machen ...
git push origin feature/new-feature

4. Pull Request zum Hauptrepository erstellen

5. Nach Review und Merge: Fork aktualisieren

Vorteile

• Entwickler arbeiten unabhängig voneinander
• Kein direkter Zugriff auf Hauptrepository nötig
• Änderungen werden durch Pull Requests eingeführt
• Perfekt für Open-Source-Projekte mit vielen Contributors

Pull Requests: Der Mechanismus

Ein Pull Request (PR) ist ein Mechanismus, um Code-Änderungen aus einem Branch in einen anderen zu integrieren, dabei aber einen Review-Prozess einzubauen.

Was ist ein Pull Request technisch?

Ein PR ist eine Anfrage an das Team: “Ich habe Änderungen in meinem Branch. Bitte prüft sie und merged sie in den Hauptbranch.”

Ablauf

1. Feature-Branch erstellen und pushen:

git switch -c feature/new-api
# ... Entwicklung ...
git push origin feature/new-api

2. Pull Request erstellen (auf GitHub/GitLab/Bitbucket)

3. Code Review: Teammitglieder prüfen den Code, kommentieren, schlagen Änderungen vor

4. Änderungen einarbeiten (falls nötig)

5. Genehmigung und Merge: Nach Approval wird der PR gemerged

Vorteile

• Codequalität durch Review-Prozess
• Diskussion und Feedback vor Integration
• Dokumentation von Änderungen
• Schutz des Hauptbranches

Hinweis: Die Team-Prozesse rund um Pull Requests (Code Review Best Practices, Communication) lernst du in Lerneinheit Kollaboration und verteilte Workflows.

Rebase: Die Technik

Rebase ist eine Alternative zum Merging. Es verschiebt die Basis deines Branches auf einen neuen Stand, oft den aktuellen Stand des Hauptbranches.

Was macht Rebase?

Stell dir vor: Du arbeitest an feature/auth, während andere main aktualisieren. Mit Rebase kannst du deine Commits so umordnen, als hättest du von Anfang an auf der neuesten main-Version gearbeitet.

Rebase durchführen

Situation: Du bist in feature/auth, main hat neue Commits

git switch feature/auth
git rebase main

Git nimmt deine Commits aus feature/auth und wendet sie auf den neuesten main-Stand an.

Unterschied zu Merge

	Merge	Rebase
Historie	Erstellt Merge-Commit, zeigt parallele Entwicklung	Lineare Historie, als wäre alles nacheinander passiert
Commits	Behält alle Original-Commits	Schreibt Commit-Historie um
Konflikte	Einmal lösen	Pro Commit lösen (kann aufwendiger sein)

Wann Rebase statt Merge?

• Für eine saubere, lineare Git-Historie
• Vor dem Pushen eines Feature-Branches

Cherry-Picking

Cherry-Picking ermöglicht es dir, einzelne Commits aus einem Branch in einen anderen zu übernehmen, ohne die gesamte Historie zu übertragen.

Wann ist das nützlich?

• Bugfix aus einem Feature-Branch soll schnell in main, ohne auf das ganze Feature zu warten
• Hotfix soll sowohl in main als auch in develop landen
• Spezifische Änderung aus einem verworfenen Branch soll gerettet werden

Cherry-Pick durchführen

Schritt 1: Finde die Commit-Hash des gewünschten Commits:

git log feature/payment  # Zeigt Commits an

Schritt 2: Wechsle zum Zielbranch:

git switch main

Schritt 3: Cherry-Pick den Commit:

git cherry-pick abc1234

Der Commit abc1234 wird in main übernommen.

Wichtige Hinweise

• Cherry-Picking verändert die Commit-Historie
• Kann zu Duplikaten führen (derselbe Fix in zwei Branches)
• Sollte sparsam eingesetzt werden

Best Practice: Nutze Cherry-Pick nur für dringende Einzelfälle. Für reguläre Integration nutze Merge oder Rebase.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung

Zusammenfassung:

Branches erstellen und verwalten

Branches ermöglichen parallele Entwicklungslinien ohne Beeinflussung des Hauptcodes.

• Branch erstellen: git branch <name> erstellt einen neuen Branch
• Branch wechseln: git switch <name> wechselt zu einem Branch (modern, nicht checkout)
• Beides kombiniert: git switch -c <name> erstellt und wechselt in einem Schritt
• Branches anzeigen: git branch zeigt alle lokalen Branches
• Branch löschen: git branch -d <name> löscht gemergede Branches

Merging durchführen

Merging überführt Änderungen aus einem Branch in einen anderen.

• Workflow: Zielbranch auschecken → git pull → git merge <feature-branch>
• Fast-Forward Merge: Verschiebt nur den Zeiger, keine neue Historie
• Recursive Merge: Erstellt Merge-Commit bei parallelen Entwicklungslinien

Merge-Konflikte auflösen

Konflikte entstehen bei gleichzeitiger Änderung derselben Zeilen.

• Erkennen: git status zeigt “unmerged” Dateien
• Markierungen: <<<<<<< HEAD, =======, >>>>>>> branch-name
• Auflösen: Konflikte manuell bearbeiten → Markierungen entfernen → git add → git commit
• Best Practice: Mit Teammitgliedern kommunizieren bei komplexen Konflikten

Branching-Workflows

Teams nutzen strukturierte Workflows für koordinierte Zusammenarbeit.

• Feature-Branch Workflow: Ein Branch pro Feature, einfach und klar
• Git-Flow: Strukturiert mit main, develop, feature/*, release/*, hotfix/*
• Forking Workflow: Jeder Entwickler hat eigene Repository-Kopie (Open Source)
• Pull Requests: Code-Review-Prozess vor Integration

Rebase und Cherry-Picking

Alternativen zum klassischen Merge für spezielle Szenarien.

• Rebase: Verschiebt Branch-Basis auf neuen Stand, lineare Historie
• Unterschied zu Merge: Keine Merge-Commits, schreibt Historie um
• Cherry-Pick: Übernimmt einzelne Commits in anderen Branch
• Anwendungsfall: Bugfix schnell in main ohne ganzes Feature

Ausblick:

In der nächsten Lerneinheit Kollaboration und verteilte Workflows lernst du, wie Teams mit Git in verteilten Umgebungen effektiv zusammenarbeiten. Du erfährst, wie du Remote-Repositories verwaltest, mit git fetch, git pull und git push arbeitest und wie Code-Review-Prozesse in der Praxis ablaufen.

---