Was ist der Unterschied zwischen rebase und merge?

Question

Accepted Answer

Sowohl **merge** als auch **rebase** integrieren Änderungen von einem Branch in einen anderen, tun dies aber auf unterschiedliche Weise: merge **bewahrt die Historie** mit einem Merge-Commit, während rebase **die Historie umschreibt**, um eine lineare Abfolge zu erstellen. Das Verständnis des Unterschieds und wann man welches Verfahren einsetzt, ist wichtig.

## Merge — bewahrt die Historie (kombiniert)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — schreibt für eine lineare Historie um (wiederholt)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **verschiebt** die Commits deines Branches, um von der Spitze eines anderen Branches zu beginnen und erstellt neue Commits — was eine saubere, lineare Historie erzeugt.

## Die goldene Regel des Rebasing

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## Wann man welches einsetzt

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## Warum es wichtig ist

Das Verständnis des Unterschieds zwischen rebase und merge ist wichtig, weil beide Änderungen integrieren, aber mit grundlegend unterschiedlichen Auswirkungen auf die Historie, und die richtige (und sichere) Wahl ist entscheidend — daher ist es wertwolles Git-Wissen, das auch häufig diskutiert wird.

Die zentrale Unterscheidung — **merge bewahrt die Historie** (erstellt einen Merge-Commit, der aufzeichnet, dass Branches kombiniert wurden, und hält die wahre Entwicklungshistorie), während **rebase die Historie umschreibt** (Commits auf die Spitze eines anderen Branches wiederholt, um eine saubere, lineare Abfolge zu erstellen, als wäre die Arbeit auf dem neuesten Code durchgeführt worden) — beeinflusst, wie die Projekthistorie aussieht und gelesen wird.

Das Verständnis der Kompromisse (merge: genau, aber möglicherweise unübersichtlich mit Merge-Commits; rebase: sauber und linear, aber Commits werden umgeschrieben) hilft dabei zu entscheiden, ob du wahre Historie oder lineare Sauberkeit bevorzugst.

Am wichtigsten ist das Verständnis der **goldenen Regel des Rebasing** — **commits niemals rebasen, die gepusht/geteilt wurden** — essentiell, weil rebase Commits umschreibt (gibt ihnen neue Hashes), daher divergiert die umgeschriebene gemeinsame Historie von dem, was Mitarbeiter haben, was ernsthafte Verwirrung und Konflikte verursacht; rebase ist nur für lokale, nicht gepushte Commits sicher.

Diese Sicherheitsregel ist vital und eine häufige Quelle von Problemen, wenn sie verletzt wird.

Das Verständnis **wann man welches einsetzt** (merge zum Integrieren von gemeinsamen Branches und zum Bewahren der Historie, oft der Team-Standard zum Mergen von Features via Pull Requests; rebase zum Aufräumen lokaler Commits vor dem Teilen oder zum Halten eines Feature-Branches linear auf dem neuesten Stand — nur auf lokalen Commits) spiegelt solide Git-Praxis wider.

Da das Integrieren von Änderungen grundlegend ist und die Merge-vs-Rebase-Wahl (mit ihren Auswirkungen auf die Historie und Sicherheit) eine häufige Entscheidung und ein Interviewthema ist, ist das Verständnis des Unterschieds — ihre Auswirkungen auf die Historie, die kritische goldene Regel und wann man welches einsetzt — wertwolles, praktisch wichtiges Git-Wissen, das zentral für die sichere Aufrechterhaltung einer sauberen Historie ist, und eine häufig diskutierte Unterscheidung, die jeder Entwickler verstehen sollte.