Rebasen oder Mergen
Vergleichen Sie Rebasen und Mergen und lernen Sie, wann Sie welche Methode für einen sauberen, linearen Verlauf verwenden sollten.
Rebasen oder Mergen ist eine kostenlose DevOps Bootcamp-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des DevOps Bootcamp-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.
Mergen oder Rebasen? Die Entscheidung
Bei der Arbeit mit Git stellen Sie häufig fest, dass Ihr Branch von einem anderen abweicht, etwa Ihr feature-Branch von main.
Wie führen Sie diese Änderungen zusammen? Git bietet dafür zwei grundlegende Strategien: Mergen und Rebasen. Beide integrieren Änderungen, gehen dabei jedoch grundsätzlich unterschiedlich vor und führen daher zu unterschiedlichen Projekthistorien.
Mergen: Historien zusammenführen
Mergen ist Gits standardmäßige Methode, Änderungen zu integrieren. Wenn Sie einen Branch in einen anderen mergen, nimmt Git den Inhalt des Quell-Branches und führt ihn mit dem Ziel-Branch zusammen.
Das entscheidende Merkmal eines Merges ist, dass dabei ein neuer Merge-Commit erstellt wird. Dieser Commit hat zwei Eltern-Commits und zeigt damit ausdrücklich, dass zwei voneinander abweichende Historien zusammengeführt wurden. Die genaue Historie beider Branches bleibt erhalten.
Einen Git-Merge durchführen
Sehen wir uns einen einfachen Merge an. Wir erstellen einen feature-Branch, fügen einen Commit hinzu und führen ihn anschließend wieder in main zusammen.
git init my_merge_project
cd my_merge_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"
git branch feature
git checkout feature
echo "Feature A" >> feature.txt
git add .
git commit -m "Add feature A"
git checkout main
echo "Main update" >> main.txt
git add .
git commit -m "Update main"
git merge feature
git log --oneline --graphMerge: Vor- und Nachteile
Mergen ist unkompliziert und sicher für gemeinsam genutzte Branches, kann aber zu einer „unübersichtlichen“ Historie führen.
- Vorteile:
- Die genaue Commit-Historie bleibt erhalten.
- Nicht destruktiv: Vorhandene Commits werden nicht umgeschrieben.
- Einfach anzuwenden und zu verstehen.
- Nachteile:
- Kann durch viele Merge-Commits zu einer „rauschenden“ Historie führen.
- Der Graph kann durch das Zusammenführen vieler Branches komplex wirken.
Rebasen: Historie umschreiben
Rebasen ist eine Alternative zum Mergen. Dabei wird eine Folge von Commits auf eine neue Basis verschoben oder mit ihr kombiniert, um Änderungen zu integrieren. Statt einen Merge-Commit zu erstellen, schreibt Rebasen die Projekthistorie um.
Im Wesentlichen werden die Commits Ihres Feature-Branches auf dem neuesten Commit des Ziel-Branches „wiedergegeben“. Dadurch entsteht der Eindruck, als hätten Sie Ihre Arbeit dort begonnen. So entsteht eine lineare Historie ohne zusätzliche Merge-Commits.
Einen Git-Rebase durchführen
Sehen wir uns dasselbe Szenario nun mit Rebase an. Wir führen für unseren feature-Branch einen Rebase auf main durch.
Beachten Sie, wie der Commit des feature-Branches auf dem neuesten Commit von main erneut angewendet wird und ein Fast-Forward-Merge anschließend main darauf zeigen lässt.
git init my_rebase_project
cd my_rebase_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"
git branch feature
git checkout feature
echo "Feature B" >> feature.txt
git add .
git commit -m "Add feature B"
git checkout main
echo "Main update 2" >> main.txt
git add .
git commit -m "Update main 2"
git checkout feature
git rebase main
git checkout main
git merge feature
git log --oneline --graphRebase: Vor- und Nachteile
Rebasen erzeugt eine übersichtliche Historie, bringt aber eine wichtige Warnung für gemeinsam genutzte Branches mit sich.
- Vorteile:
- Erzeugt eine übersichtliche, lineare Projekthistorie.
- Die Commit-Historie lässt sich leichter durchsuchen und verstehen.
- Commits können vor der Integration bereinigt (zusammengefasst oder neu angeordnet) werden.
- Nachteile:
- Schreibt die Commit-Historie um.
- Kann gefährlich sein, wenn es auf Commits angewendet wird, die bereits in ein gemeinsam genutztes (öffentliches) Remote-Repository gepusht wurden.
Merge vs. Rebase: Der Vergleich
Hier eine kurze Zusammenfassung der wichtigsten Unterschiede:
- Merge:
- Erstellt einen neuen Merge-Commit.
- Bewahrt die vollständige, genaue Historie.
- Nicht destruktiv.
- Der Graph kann komplex sein.
- Rebase:
- Schreibt die Historie ohne Merge-Commit um.
- Erzeugt eine lineare Historie.
- Destruktiv (ändert Commit-IDs).
- Der Graph ist sehr übersichtlich.
Ihre Strategie wählen
Wann sollten Sie also welche Strategie verwenden?
- Verwenden Sie Merge, wenn:
- Sie an öffentlichen oder gemeinsam genutzten Branches arbeiten (z. B.
main,develop). - Sie die genaue Historie Ihres Projekts bewahren müssen.
- Sie ausdrücklich zeigen möchten, wann voneinander abweichende Historien zusammengeführt wurden.
- Verwenden Sie Rebase, wenn:
- Sie an Ihrem privaten Feature-Branch arbeiten, bevor Sie ihn pushen.
- Sie eine übersichtliche, lineare Historie wünschen.
- Sie die Commits Ihres Feature-Branches vor der Integration aufräumen möchten (z. B. zusammenfassen oder neu anordnen).
Die goldene Regel: Rebasten Sie niemals Commits, die bereits in ein gemeinsam genutztes Remote-Repository gepusht wurden! Das Rebasen einer gemeinsam genutzten Historie kann für alle Beteiligten große Probleme verursachen.
Kurze Überprüfung: Merge oder Rebase?
Betrachten Sie die Eigenschaften der beiden wichtigsten Integrationsstrategien von Git.
Rückblick: Merge vs. Rebase
In dieser Lektion haben wir die beiden grundlegenden Möglichkeiten von Git zum Integrieren von Änderungen behandelt: Mergen und Rebasen.
- Mergen führt Historien mit einem neuen Merge-Commit zusammen und bewahrt dabei alle ursprünglichen Commits.
- Rebasen schreibt die Historie um und erzeugt durch das Verschieben von Commits einen linearen Verlauf.
Wählen Sie abhängig vom Workflow Ihres Teams mit Bedacht und denken Sie an die goldene Regel: Rebasen Sie niemals eine öffentliche Historie! Dieses Verständnis ist entscheidend für einen übersichtlichen und kollaborativen Git-Workflow.
Häufig gestellte Fragen
Ist die Lektion „Rebasen oder Mergen“ kostenlos?
Ja — der vollständige Text von „Rebasen oder Mergen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des DevOps Bootcamp-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Rebasen oder Mergen“?
Vergleichen Sie Rebasen und Mergen und lernen Sie, wann Sie welche Methode für einen sauberen, linearen Verlauf verwenden sollten. Du übst DevOps Bootcamp mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um DevOps Bootcamp zu starten?
Keine Vorkenntnisse erforderlich. DevOps Bootcamp auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.
Wie lange dauert die Lektion „Rebasen oder Mergen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser DevOps Bootcamp-Lektion Code schreiben und ausführen?
Ja. Jede DevOps Bootcamp-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Workflow mit Feature-Branches
- Einführung in den Gitflow-Workflow
- Rebasen oder Mergen
- Trunk-Based Development