Merge vs. Rebase

In L5 hast du Branching gelernt. Aber wie führt man Branches wieder zusammen? Es gibt zwei Wege: git merge und git rebase. Beide bringen Commits zweier Branches in einen – aber mit fundamental unterschiedlichen Historien. Diese Lektion erklärt beide und sagt, wann du welchen nimmst.

Diese Entscheidung ist im Team manchmal religiös – „merge-camp" vs. „rebase-camp". In Wahrheit haben beide ihren Platz. Wer den Unterschied versteht, kann sich der Diskussion souverän stellen.

1) Die Ausgangssituation

Du hast einen main-Branch und einen feature-Branch. Auf beiden wurde commitet, seit sie sich gabelten. Jetzt sollen die Änderungen vom feature-Branch in main:

2) git merge – die ehrliche Variante

Ein Merge erstellt einen neuen Commit mit zwei Eltern. Die Historie zeigt: hier kamen zwei Linien wieder zusammen. Beide ursprünglichen Branch-Verläufe bleiben sichtbar.

3) git rebase – die saubere Variante

Ein Rebase nimmt die Commits eines Branches und „setzt sie um" auf einen anderen. Die Historie sieht aus, als wäre alles linear passiert. Es entsteht kein Merge-Commit:

4) Merge vs. Rebase – Vor- und Nachteile

5) Die goldene Regel des Rebase

6) Merge-Strategien

Wenn du git merge ausführst, gibt es verschiedene Varianten – je nach Situation und Konfiguration:

7) Interaktiver Rebase – die Profi-Variante

git rebase -i (interaktiv) ist eines der mächtigsten Git-Features. Es erlaubt dir, deine Commit-Historie vor dem Push umzuschreiben: Commits zusammenfassen, umbenennen, umsortieren, weglassen.

$ git rebase -i HEAD~3

# Im Editor erscheint:
pick a3f7c9d feat: Login-Form
pick b2e5d8a fix typo
pick c4f1a2b fix typo nochmal

# Du editierst zu:
pick a3f7c9d feat: Login-Form
squash b2e5d8a fix typo
squash c4f1a2b fix typo nochmal

# → die drei Commits werden zu einem zusammengefasst

Befehle: pick (behalten), squash/s (zusammenfassen), reword/r (Nachricht ändern), edit/e (Commit anpassen), drop/d (löschen), fixup/f (wie squash, aber Nachricht weglassen). Goldene Regel beachten!

8) Befehle im Überblick

9) Praxis: ein typischer Workflow

Du hast einen Feature-Branch, der schon ein paar Tage alt ist. Main hat sich weiterentwickelt. Wie syncst du deinen Branch?

Variante A – mit Merge:

git switch feature/login
git merge main          # Merge-Commit entsteht
git push                # Push wie üblich

Variante B – mit Rebase:

git switch feature/login
git rebase main          # Deine Commits werden auf main umgesetzt
git push --force-with-lease   # Force-Push, weil Hashes neu

--force-with-lease ist sicherer als --force: bricht ab, falls jemand anderes inzwischen gepushed hat. Verhindert versehentliches Überschreiben fremder Arbeit.

10) Praxis-Empfehlung

Für die meisten Teams funktioniert diese Strategie gut:

• Feature-Branches lokal mit git rebase main aktuell halten (saubere Historie).
• Beim Merge in main: Squash & Merge via PR (ein Commit pro Feature).
• Auf main selbst niemals rebasen oder mit Force-Push hantieren.
• git pull --rebase als Standard für pull einrichten: git config --global pull.rebase true.

Zusammenfassung

Merge erstellt einen Merge-Commit mit zwei Eltern – ehrliche Historie, dafür „zackig". Rebase setzt Commits auf einen anderen Branch um – lineare Historie, dafür Hashes neu. Goldene Regel: niemals geteilte Branches rebasen, nur eigene lokale. Merge-Strategien: Fast-Forward (kein Merge-Commit), No-FF (immer Merge-Commit), Squash (zu einem Commit zusammenfassen). Interaktiver Rebase (git rebase -i) zum Aufräumen lokaler Historie. Praxis: Rebase lokal, Squash-Merge im PR. Nächste Lektion: Konflikte lösen.