Git Rebase vs. Merge: Wann du welchen Weg wählst

Kaum eine Git-Frage sorgt für so viel hitzige Diskussion wie die Wahl zwischen Rebase und Merge. Beide integrieren Änderungen aus einem Branch in einen anderen – aber sie erzählen dabei völlig unterschiedliche Geschichten in deiner Historie. Dieses Tutorial zeigt, was technisch passiert, wann welche Strategie passt und welche Regeln du in Teams vereinbaren solltest.

Was Merge wirklich macht

Ein Merge nimmt zwei Entwicklungslinien und kombiniert sie zu einem neuen Commit – dem Merge-Commit. Die Historie bleibt dabei vollständig erhalten: Git zeichnet auf, dass hier zwei Zweige zusammenliefen, inklusive aller Umwege.

# Auf main: Feature-Branch integrieren
git switch main
git merge feature/neue-funktion

# Ergebnis: ein Merge-Commit mit zwei Eltern-Commits
git log --oneline --graph
# *   a3f2c1e (HEAD -> main) Merge branch 'feature/neue-funktion'
# |\
# | * b8e4d2f (feature/neue-funktion) feat: neue Funktion fertiggestellt
# | * c9d1e3a feat: Zwischenstand
# * | d4e5f6b chore: README aktualisiert
# |/

Der große Vorteil: Ehrlichkeit. Die Historie zeigt genau, wann parallel gearbeitet wurde. Der Nachteil: Bei vielen kleinen Feature-Branches wird git log schnell unleserlich – die berüchtigte „Zickzack-Historie“.

Was Rebase wirklich macht

Rebase integriert keine Branches – es schreibt Historie um. Git nimmt die Commits deines Feature-Branches, entfernt sie und spielt sie auf der aktuellen Spitze des Ziel-Branches erneut ab. Jeder Commit bekommt dabei einen neuen Hash, weil sein Elternteil ein anderer ist.

# Auf dem Feature-Branch: auf main umsetzen
git switch feature/neue-funktion
git rebase main

# Danach sieht es aus, als wäre das Feature
# NACH allen main-Commits entstanden:
git log --oneline --graph
# * e7f8a9b (HEAD -> feature/neue-funktion) feat: neue Funktion fertiggestellt
# * f1a2b3c feat: Zwischenstand
# * d4e5f6b (main) chore: README aktualisiert

Der entscheidende Unterschied

Zusammengefasst in einem Satz: Merge bewahrt die Geschichte, Rebase erschafft eine neue. Merge sagt „diese beiden Linien liefen parallel und wurden zusammengeführt“. Rebase sagt „so, als hätte ich nie abgezweigt“.

Praktisch heißt das für deine Entscheidung:

• Merge, wenn die Historie die Zusammenarbeit dokumentieren soll – typisch für Feature-Branches, die von mehreren Personen bearbeitet wurden.
• Rebase, wenn du deine eigene Arbeit auf den aktuellen Stand bringen willst, bevor sie integriert wird – typisch für Solo-Branches.

Die goldene Mitte: Rebase vor dem Merge

In der Praxis hat sich ein Muster durchgesetzt, das beide Welten verbindet: Rebase deinen Feature-Branch vor dem Merge auf main – und merge dann mit --no-ff. So ist die Historie linear sauber, aber der Merge-Commit dokumentiert trotzdem, dass hier ein Feature integriert wurde.

# 1. Feature auf den aktuellen main-Stand umsetzen
git switch feature/neue-funktion
git rebase main

# 2. Konflikte? Rebase anhalten und Schritt für Schritt lösen
git status                 # zeigt die konfliktbehafteten Dateien
# ... Konflikte in der IDE oder im Editor lösen ...
git add .                  # Lösungen stagen
git rebase --continue      # mit dem nächsten Commit fortfahren
# Abbrechen geht jederzeit: git rebase --abort

# 3. Merge mit --no-ff: Merge-Commit erzwingen
git switch main
git merge --no-ff feature/neue-funktion

Regeln für Teams

Damit alle mit derselben Strategie arbeiten, lohnt sich eine kurze Vereinbarung im Team. Ein bewährtes Set:

• Feature-Branches werden vor dem Merge auf main gerebased.
• Gemerged wird mit --no-ff, damit Features sichtbar bleiben.
• Der main-Branch wird nie gerebased – gepushte, geteilte Commits sind tabu.
• Interaktiver Rebase (git rebase -i) räumt den eigenen Branch auf: Commits squashed, Messages korrigiert.

Fazit

Rebase und Merge sind keine Konkurrenten, sondern Werkzeuge für unterschiedliche Momente: Rebase hält deine eigene Arbeit linear und aktuell, Merge dokumentiert Integration. Wer beides gezielt einsetzt – rebase vor dem Merge, --no-ff beim Merge – bekommt eine Historie, die man Monate später noch versteht.