Git Rebase vs Merge: Vollständiger Leitfaden mit realen Beispielen und wann man sie jeweils verwendet

{
“@context”: “https://schema.org”,
“@type”: “TechArticle”,
“headline”: “Git Rebase vs Merge: Vollständiger Leitfaden mit realen Beispielen und wann man sie jeweils verwendet”,
“description”: “Hören Sie auf zu raten: Wann Sie Git Merge vs. Git Rebase verwenden sollten, interaktive Rebase-Workflows, Squashing-Commits und die goldene Regel, die Sie niemals brechen dürfen.”,
“url”: “https://techpulsesite.com/git-rebase-vs-merge-complete-guide-with-de/”,
“datePublished”: “2026-06-26T16:20:00+00:00”,
“dateModified”: “2026-06-29T04:14:32+00:00”,
“author”: {
“@type”: “Organization”,
“name”: “TechPulse Editorial Team”,
“url”: “https://techpulsesite.com”
},
“publisher”: {
“@type”: “Organization”,
“name”: “TechPulse”,
“url”: “https://techpulsesite.com”
},
“inLanguage”: “de”
}

{
“@context”: “https://schema.org”,
“@type”: “TechArticle”,
“headline”: “Git Rebase vs Merge: Vollständiger Leitfaden mit realen Beispielen und wann man sie jeweils verwendet”,
“description”: “Hören Sie auf zu raten: Wann Sie Git Merge vs. Git Rebase verwenden sollten, interaktive Rebase-Workflows, Squashing-Commits und die goldene Regel, die Sie niemals brechen dürfen.”,
“url”: “https://techpulsesite.com/git-rebase-vs-merge-complete-guide-with-de/”,
“datePublished”: “2026-06-26T16:20:00+00:00”,
“dateModified”: “2026-06-21T06:02:18+00:00”,
“author”: {
“@type”: “Organization”,
“name”: “TechPulse Editorial Team”,
“url”: “https://techpulsesite.com”
},
“publisher”: {
“@type”: “Organization”,
“name”: “TechPulse”,
“url”: “https://techpulsesite.com”
},
“inLanguage”: “de”
}

DasGit Rebase vs Merge Die Debatte ist eine der häufigsten Workflow-Fragen, mit denen Entwickler konfrontiert sind. Beide integrieren Änderungen von einem Zweig in einen anderen – aber sie machen es anders, hinterlassen einen unterschiedlichen Verlauf und haben unterschiedliche geeignete Anwendungsfälle. In dieser Anleitung werden beide Befehle mit realen Beispielen behandelt, sodass Sie genau wissen, wann Sie die einzelnen Befehle verwenden müssen.

Der Kernunterschied

git merge Erstellt einen Merge-Commit, der zwei Zweigverläufe miteinander verbindet. Der Verlauf zeichnet auf, dass eine Zusammenführung stattgefunden hat – zerstörungsfrei, bewahrt den Kontext.

git rebase spielt Ihre Commits über einem anderen Zweig ab und schreibt den Commit-Verlauf so um, dass es so aussieht, als ob Sie vom letzten Punkt aus verzweigt wären. Erstellt einen linearen Verlauf – keine Merge-Commits.

# Starting state:
#   A---B---C  main
#        #         D---E  feature

# After git merge:
#   A---B---C---F  main  (F = merge commit)
#              /
#         D---E  feature

# After git rebase:
#   A---B---C---D'---E'  main  (D', E' = replayed commits with new hashes)

git merge – Bewahrt die wahre Geschichte

# Merge feature into main
git checkout main
git merge feature

# Creates a merge commit:
# Merge branch 'feature' into main
# (includes all commits from feature branch)

# Fast-forward merge (no merge commit if possible)
git merge --ff-only feature

Verwenden Sie Merge, wenn:

• Zusammenführen eines abgeschlossenen Feature-Zweigs in main/master
• Arbeiten an öffentlichen/gemeinsam genutzten Zweigen (niemals ein Rebase durchführen)
• Sie möchten, dass im Verlauf angezeigt wird, dass eine Zusammenführung stattgefunden hat
• Es ist besser, Konflikte einmal zu lösen, als sie Commit für Commit zu lösen

git rebase – Erstellt einen linearen Verlauf

# Rebase feature onto main (move feature's commits on top of main)
git checkout feature
git rebase main

# Now feature contains main's latest commits + your commits on top
# Switch to main and fast-forward merge
git checkout main
git merge feature  # fast-forward, no merge commit

Verwenden Sie Rebase, wenn:

• Aktualisieren eineslokal Feature-Zweig mit den neuesten Änderungen vom Hauptzweig vor dem Öffnen eines PR
• Commit-Verlauf vor dem Zusammenführen bereinigen (Fix-Commits löschen)
• Sie möchten ein sauberes, lineares Git-Protokoll

Die goldene Regel: Gemeinsame Zweige niemals umbasieren

Rebase schreibt Commit-Hashes neu. Wenn Sie einen Zweig, den Ihre Kollegen ausgecheckt haben, umbasieren, werden ihre lokalen Kopien unterschiedliche Commit-Hashes haben – was zu einer alptraumhaften Divergenz führt.

# NEVER do this:
git checkout main
git rebase feature  # rewrites main's history — everyone's fork breaks

# SAFE: only rebase your local feature branch
git checkout feature      # your private branch
git rebase main           # safe — nobody else has this branch

Interaktives Rebase – Bereinigen Ihres Verlaufs

Mit der interaktiven Rebase (git rebase -i) können Sie Commits vor dem Zusammenführen bearbeiten, stauchen, neu anordnen oder löschen. Unverzichtbar für saubere Pull-Anfragen.

# Squash last 3 commits into one
git rebase -i HEAD~3

# Opens an editor showing:
# pick a1b2c3 Add user login endpoint
# pick d4e5f6 fix typo
# pick g7h8i9 fix linting errors

# Change to:
# pick a1b2c3 Add user login endpoint
# squash d4e5f6 fix typo
# squash g7h8i9 fix linting errors

# Result: one clean commit "Add user login endpoint"

Interaktive Rebase-Befehle:

Umgang mit Rebase-Konflikten

# Rebase stopped due to conflict
git rebase main
# CONFLICT in app/models.py
# Auto-merging app/models.py
# error: could not apply a1b2c3... Add user model

# Fix the conflict in your editor, then:
git add app/models.py
git rebase --continue

# If things get messy, abort entirely:
git rebase --abort

Im Gegensatz zu Merge-Konflikten (die einmal gelöst werden) können Rebase-Konflikte pro Commit auftreten – ein Grund dafür, dass Merge manchmal für lang laufende Branches mit vielen Commits vorzuziehen ist.

Praxisnahe Workflow-Empfehlungen

Für einen typischen Feature-Branch-Workflow:

# 1. Create feature branch
git checkout -b feature/user-auth

# 2. Work on your feature, commit frequently
git commit -m "wip: add login form"
git commit -m "fix: validation edge case"

# 3. Before opening PR: clean up and update
git fetch origin
git rebase origin/main          # get latest main
git rebase -i origin/main       # squash WIP commits

# 4. Push and open PR
git push -f origin feature/user-auth  # force push after rebase is OK on your own branch

# 5. After approval: merge into main (via PR)
# Use squash-and-merge or merge commit in GitHub/GitLab

Entscheidungsbaum zum Zusammenführen und erneuten Basieren

• Handelt es sich um einen öffentlichen/gemeinsamen Zweig? →Immer zusammenführen, niemals rebasieren
• Aktualisieren Sie Ihren lokalen Feature-Zweig mit main? →Rebase
• Abgeschlossene Funktion in Hauptfunktion zusammenführen? →Zusammenführen (Kontext bleibt erhalten)
• WIP-Commits vor einer PR bereinigen? →Interaktive Rebase
• Team bevorzugt lineare Geschichte? →Rebase für Feature-Branches, Merge für Integration

Häufig gestellte Fragen

F: Muss sich mein Team auf eine Strategie einigen?
A: Ja. Das zufällige Mischen von Merge und Rebase führt zu einem verwirrenden Verlauf. Wählen Sie einen Ansatz aus und dokumentieren Sie ihn in Ihrem CONTRIBUTING.md.

F: Ist git merge –squash dasselbe wie Squash Rebase?
A: Ähnliches Ergebnis (ein sauberer Commit), aber unterschiedliche Mechaniken. --squash erstellt eine einzelne nicht festgeschriebene Änderung, die Sie dann manuell festschreiben. Squash Rebase schreibt den Zweigverlauf direkt neu.

F: Sollte ich git pull –rebase verwenden?
A: Viele Teams konfigurieren dies als Standard (git config --global pull.rebase true). Es vermeidet unnötige Merge-Commits beim Pullen – oft sauberer für schnelllebige Teams.

F: Was passiert mit den ursprünglichen Commits nach dem Rebase?
A: Sie werden nicht sofort gelöscht – sie werden zu baumelnden Commits. Die Git-Garbage Collection entfernt sie nach ca. 30 Tagen. Verwenden Siegit reflog um sie bei Bedarf wiederherzustellen.

F: Wie mache ich einen Rebase rückgängig?
A: git reflog zeigt Ihren Verlauf der HEAD-Positionen. Suchen Sie den Commit-Hash vor dem Rebase und danngit reset --hard HASH. Dies funktioniert, solange Sie den neu erstellten Zweig nicht öffentlich gepusht haben.

Fazit

Verwenden Sie Merge, um abgeschlossene Zweige zu integrieren und den Verlaufskontext beizubehalten. Verwenden Sie Rebase, um Ihren Feature-Zweig auf dem neuesten Stand zu halten und um Commits vor der Überprüfung zu bereinigen. Die wichtigste Regel: Rebasieren Sie niemals Zweige, von denen aus andere arbeiten. Darüber hinaus hängt die Wahl von der Präferenz Ihres Teams für die Lesbarkeit des Verlaufs ab. Beide Befehle sind wesentliche Fähigkeiten für jeden Entwickler, der in einem echten Team arbeitet.