Rebase vs Merge

Du kennst bereits git merge - jetzt lernst du git rebase kennen, eine alternative Methode, um Branches zusammenzufuehren. Rebase erzeugt eine sauberere, lineare Historie, hat aber Regeln, die du beachten musst. In diesem Kapitel lernst du beide Strategien im Vergleich.

Was ist Rebase?

Rebase bedeutet woertlich “die Basis aendern”. Statt einen Merge-Commit zu erstellen, verschiebt Rebase deine Commits auf die Spitze eines anderen Branches:

Merge vs. Rebase - Visuell

Mit Merge:

main:    A ── B ── C ── M (Merge-Commit)
                   \   /
feature:            D ── E

Mit Rebase:

main:    A ── B ── C
                    \
feature:             D' ── E' (verschobene Commits)

Nach dem Rebase und Merge:

main:    A ── B ── C ── D' ── E' (lineare Historie!)

Der Unterschied: Mit Rebase gibt es keinen Merge-Commit und die Historie ist eine gerade Linie.

Rebase in der Praxis

Szenario: Feature-Branch aktualisieren

Du arbeitest an einem Feature und in der Zwischenzeit hat sich main weiterentwickelt:

main:    A ── B ── C ── D (neue Commits von anderen)
              \
feature:       E ── F (deine Arbeit)

Mit Merge aktualisieren

git switch feature
git merge main

main:    A ── B ── C ── D
              \         \
feature:       E ── F ── M (Merge-Commit)

Mit Rebase aktualisieren

git switch feature
git rebase main

main:    A ── B ── C ── D
                         \
feature:                  E' ── F' (deine Commits, neu basiert)

Deine Commits werden an das Ende von main angehaengt, als haettest du erst jetzt mit der Arbeit begonnen.

Rebase Schritt fuer Schritt

Schritt 1: Auf dem Feature-Branch sein

git switch feature/navigation

Schritt 2: Rebase ausfuehren

git rebase main

Successfully rebased and updated refs/heads/feature/navigation.

Schritt 3: Ergebnis pruefen

git log --oneline --graph

* f6a7b8c (HEAD -> feature/navigation) style: Navigation-Styling
* e5f6a7b feat: Navigation-Grundstruktur
* d4e5f6a (main) feat: Kontaktformular
* c3d4e5f feat: Footer
* b2c3d4e Initiales Projekt

Perfekt linear! Keine Merge-Commits, keine Veraestelungen.

Konflikte beim Rebase

Wie beim Merge koennen auch beim Rebase Konflikte auftreten. Der Unterschied: Beim Rebase musst du Konflikte moeglicherweise fuer jeden Commit einzeln loesen.

Konflikt-Ablauf

git rebase main

CONFLICT (content): Merge conflict in index.html
error: could not apply e5f6a7b... feat: Navigation-Grundstruktur

Konflikt loesen

# 1. Konflikt in der Datei loesen (wie bei Merge)
# ... Datei bearbeiten, Marker entfernen ...

# 2. Geloeste Datei stagen
git add index.html

# 3. Rebase fortsetzen
git rebase --continue

Wenn es weitere Commits mit Konflikten gibt, wiederholt sich der Prozess.

Rebase abbrechen

git rebase --abort

Setzt alles auf den Zustand vor dem Rebase zurueck.

Einen Commit ueberspringen

git rebase --skip

Ueberspringt den aktuellen Commit (Vorsicht: Aenderungen gehen verloren!).

Merge vs. Rebase - Der Vergleich

Aspekt	Merge	Rebase
Historie	Zeigt alle Branches	Linear, sauber
Merge-Commits	Ja	Nein
Konflikte	Einmal loesen	Pro Commit loesen
Sicherheit	Sehr sicher	Vorsicht bei oeffentlichen Branches
Komplexitaet	Einfach	Etwas komplexer
Nachvollziehbarkeit	Zeigt Branch-Struktur	Zeigt nur Ergebnis

Die goldene Rebase-Regel

Rebase NIEMALS oeffentliche Branches, die andere nutzen!

Rebase aendert die Commit-Hashes. Wenn jemand anderes auf deinen Commits aufbaut und du rebased, stimmen die Hashes nicht mehr ueberein.

# OKAY: Eigenen Feature-Branch rebasen
git switch feature/mein-feature
git rebase main

# GEFAEHRLICH: main rebasen
git switch main
git rebase feature/something  # NIEMALS!

Faustregel

• Rebase deinen Feature-Branch auf main - okay!
• Rebase main auf irgendwas - niemals!
• Rebase einen Branch, den nur du nutzt - okay!
• Rebase einen Branch, den andere gepullt haben - niemals!

Interaktiver Rebase

Mit git rebase -i kannst du deine Commits vor dem Merge aufraeumen:

git rebase -i main

Git oeffnet deinen Editor mit einer Liste der Commits:

pick e5f6a7b feat: Navigation-Grundstruktur
pick f6a7b8c style: Navigation-Styling
pick a1b2c3d fix: Tippfehler in Navigation
pick b2c3d4e fix: Noch ein Tippfehler

Verfuegbare Aktionen

Aktion	Beschreibung
pick	Commit behalten wie er ist
reword	Commit behalten, Message aendern
squash	Mit vorherigem Commit zusammenfassen
fixup	Wie squash, aber Message verwerfen
drop	Commit entfernen
edit	Commit bearbeiten

Beispiel: Commits aufraemen

Aendere die Datei so:

pick e5f6a7b feat: Navigation-Grundstruktur
pick f6a7b8c style: Navigation-Styling
fixup a1b2c3d fix: Tippfehler in Navigation
fixup b2c3d4e fix: Noch ein Tippfehler

Ergebnis: Die Tippfehler-Fixes werden in die vorherigen Commits integriert. Statt vier Commits hast du zwei saubere.

Pull mit Rebase

Statt git pull (fetch + merge) kannst du auch git pull --rebase (fetch + rebase) nutzen:

git pull --rebase origin main

Das vermeidet die haeufigen “Merge branch ‘main’ of …” Commits.

Als Standard konfigurieren

git config --global pull.rebase true

Wann Merge, wann Rebase?

Verwende Merge wenn:

• Du im Team arbeitest und die Branch-Historie wichtig ist
• Der Feature-Branch oeffentlich ist (andere arbeiten darauf)
• Du Konflikte nur einmal loesen moechtest
• Du Anfaenger bist und auf Nummer sicher gehen willst

Verwende Rebase wenn:

• Du eine saubere, lineare Historie bevorzugst
• Du an einem eigenen Feature-Branch arbeitest
• Du deine Commits vor dem Merge aufraeumen moechtest
• Du keine Merge-Commits in der Historie haben willst

Der kombinierte Workflow (empfohlen)

Viele Teams nutzen diese Kombination:

# 1. Feature-Branch auf main rebasen
git switch feature/navigation
git rebase main

# 2. Dann mit Merge (--no-ff) in main einfuegen
git switch main
git merge --no-ff feature/navigation

Das gibt dir eine saubere Feature-Historie UND einen klaren Merge-Commit in main.

Uebungen

1. Erstelle zwei Branches mit Commits und ueube git rebase
2. Erzeuge einen Rebase-Konflikt und loese ihn
3. Nutze git rebase -i um zwei Commits zu einem zu vereinen (squash)
4. Vergleiche die Historie nach Merge vs. nach Rebase mit git log --graph
5. Konfiguriere git pull --rebase als Standard

Was kommt als Naechstes?

Im naechsten Kapitel lernst du git stash kennen - eine Methode, um unfertige Aenderungen zwischenzuspeichern, wenn du schnell den Branch wechseln musst.

Zusammenfassung

• Rebase verschiebt Commits auf die Spitze eines anderen Branches
• Merge erstellt einen Merge-Commit, Rebase erzeugt eine lineare Historie
• Die goldene Regel: Rebase niemals oeffentliche Branches!
• Interaktiver Rebase (-i) ermoeglicht das Aufraeumen von Commits
• git pull --rebase vermeidet unnoetige Merge-Commits
• Bei Konflikten muss man pro Commit loesen (statt einmal bei Merge)
• Der kombinierte Workflow (Rebase + —no-ff Merge) vereint beide Vorteile