Git Rebase vs. Merge: Unterschiede verstehen und wann man sie verwendet

git merge und git rebase führen beide Arbeit von einem Branch mit einem anderen Branch zusammen, hinterlassen jedoch sehr unterschiedliche Historien. Wählen Sie den falschen Befehl auf einem gemeinsamen Branch, können Sie das Leben aller erschweren, die Ihre Commits bereits gezogen haben.

Dieser Leitfaden erklärt, was jeder Befehl tut, wie er die Commit-Historie verändert und wann Sie Merge oder Rebase in einem Team-Workflow verwenden sollten.

Was ist git merge?

git merge ist der gebräuchlichste und unkomplizierteste Weg, Änderungen von einem Branch in einen anderen zu integrieren. Wenn Sie Branch B in Branch A mergen, sucht Git nach einem gemeinsamen Vorfahren-Commit zwischen A und B. Anschließend erstellt es einen neuen Commit (einen Merge-Commit) auf Branch A, der zwei Eltern hat: die Spitze von A und die Spitze von B. Dieser Merge-Commit kapselt alle Änderungen, die seit dem gemeinsamen Vorfahren in B eingeführt wurden.

Wesentliche Merkmale von git merge:

• Bewahrt Historie: git merge erstellt einen Merge-Commit, der explizit festhält, wann und wo zwei Branches zusammengeführt wurden. Dies bewahrt den historischen Kontext Ihrer Entwicklung und zeigt die Verzweigungs- und Zusammenführungspunkte.
• Nicht-destruktiv: Es überschreibt keine vorhandenen Commits. Die ursprünglichen Commits auf beiden Branches bleiben unberührt.
• Erstellt Merge-Commits: Jeder Merge führt zu einem neuen Commit, was zu einer komplexeren und nicht-linearen Commit-Historie führen kann, die oft als Graph mit mehreren auseinanderlaufenden und wieder zusammenlaufenden Branches visualisiert wird.

Beispiel für git merge:

Angenommen, Sie haben einen main-Branch und erstellen daraus einen feature-Branch. Sie machen einige Commits auf feature, währenddessen werden neue Commits zu main hinzugefügt.

# Ausgangszustand:
# A -- B -- C (main)
#      \
#       D -- E (feature)

# Wechseln zum main-Branch
git checkout main

# Mergen des feature-Branches in main
git merge feature

# Ergebniszustand:
# A -- B -- C -- F (main)
#      \       /
#       D -- E (feature)
# Wobei F der Merge-Commit mit den Eltern C und E ist

In diesem Szenario ist Commit F ein Merge-Commit, der die Änderungen von E in main bringt. Der feature-Branch existiert weiterhin unabhängig.

Was ist git rebase?

git rebase hingegen ist eine Möglichkeit, Änderungen von einem Branch auf einen anderen zu integrieren, indem Ihre Commit-Historie umgeschrieben wird. Wenn Sie Branch B auf Branch A rebasen, nimmt Git die Commits, die nur für B spezifisch sind, speichert sie vorübergehend, setzt B auf die Spitze von A zurück und wendet dann die gespeicherten Commits nacheinander auf A an.

Wesentliche Merkmale von git rebase:

• Schreibt Historie um: git rebase erstellt neue Commits mit dem gleichen Inhalt wie die ursprünglichen, aber mit neuen Commit-IDs. Dies lässt die Commit-Historie linear erscheinen, als ob der Feature-Branch sequentiell nach den neuesten Änderungen auf dem Zielbranch entwickelt worden wäre.
• Vermeidet Merge-Commits: Es vermeidet im Allgemeinen die Erstellung von Merge-Commits, was zu einer saubereren, linearen Historie führt.
• Kann destruktiv sein: Da es die Historie umschreibt, sollte git rebase mit Vorsicht verwendet werden, insbesondere bei Branches, die mit anderen geteilt wurden.

Beispiel für git rebase:

Verwendung des gleichen Szenarios wie oben:

# Ausgangszustand:
# A -- B -- C (main)
#      \
#       D -- E (feature)

# Wechseln zum feature-Branch
git checkout feature

# Rebasen des feature-Branches auf main
git rebase main

# Ergebniszustand:
# A -- B -- C (main)
#           \
#            D' -- E' (feature)
# Wobei D' und E' neue Commits mit dem gleichen Inhalt wie D und E sind

Nach dem Rebasen von feature auf main werden die Commits D und E auf Commit C wiederholt. Der feature-Branch beginnt nun beim letzten Commit in main, und die Historie ist linear. Die ursprünglichen Commits D und E werden effektiv aufgegeben (obwohl sie für eine Weile wiederherstellbar sind).

Rebase vs. Merge: Wichtigste Unterschiede zusammengefasst

Merkmal	git merge	git rebase
Historie	Bewahrt die ursprüngliche Historie; erstellt Merge-Commits	Schreibt Historie um; erstellt eine lineare Historie
Commit-IDs	Ursprüngliche Commits bleiben unverändert	Neue Commits werden erstellt; alte werden aufgegeben
Zusammenarbeit	Sicher für gemeinsame Branches	Riskant für gemeinsame Branches; auf lokalen/privaten Branches verwenden
Komplexität	Kann zu einer komplexen, nicht-linearen Historie führen	Erstellt eine einfachere, lineare Historie
Zweck	Integriert Änderungen unter Beibehaltung des Kontexts	Integriert Änderungen durch sequentielles erneutes Anwenden

Wann man git merge verwendet

git merge ist im Allgemeinen die sicherere und gebräuchlichere Wahl, insbesondere zum Integrieren von Änderungen in langlebige Branches oder bei der Zusammenarbeit mit einem Team an einem gemeinsamen Branch.

• Integration in main/master: Wenn Sie einen abgeschlossenen Feature-Branch in Ihre Hauptentwicklungslinie (main oder master) bringen möchten, wird Merge oft bevorzugt. Dies bewahrt den Kontext der Entwicklung des Feature-Branches und markiert explizit seinen Integrationspunkt.
• Gemeinsame Branches: Wenn Sie an einem Branch arbeiten, der mit anderen Teammitgliedern geteilt wird, ist git merge fast immer die richtige Wahl. Das Rebasen eines gemeinsamen Branches kann für Ihre Mitarbeiter erhebliche Probleme verursachen, da es die Historie umschreibt, auf die sie ihre Arbeit möglicherweise bereits gestützt haben.
• Bewahrung der Release-Historie: Für wichtige Branches wie Release-Branches kann die Aufrechterhaltung einer klaren, unveränderlichen Historie mit Merge-Commits für die Überprüfung und das Verständnis vergangener Releases vorteilhaft sein.

Szenario: Mergen eines abgeschlossenen Features in main

# Angenommen, Sie sind auf dem 'main'-Branch und Ihr Feature-Branch ist aktuell
git checkout main
git merge feature-branch-name

Dies erstellt einen Merge-Commit auf main, der alle Änderungen von feature-branch-name integriert.

Wann man git rebase verwendet

git rebase ist leistungsstark, um Ihre lokalen Branches mit einem Hauptbranch aktuell zu halten und Ihre eigene Commit-Historie zu bereinigen, bevor Sie sie teilen.

• Aktualisieren lokaler Feature-Branches: Wenn Sie einen Feature-Branch erstellt haben und der main-Branch weitergegangen ist, ermöglicht das Rebasen Ihres Feature-Branches auf main, diese Upstream-Änderungen zu integrieren, ohne sofort einen Merge-Commit zu erstellen. Dies hält Ihre Feature-Branch-Commits logisch sequentiell.
• Bereinigen der lokalen Historie (Interaktives Rebase): git rebase -i (interaktives Rebase) ist unschätzbar, um Ihre eigenen Commits vor dem Pushen aufzuräumen. Sie können mehrere kleine Commits zu einem zusammenfassen (squashen), Commits neu anordnen, Commit-Nachrichten bearbeiten oder sogar Commits löschen.
• Aufrechterhalten einer linearen Projekthistorie: Wenn Ihr Team einen Workflow bevorzugt, der eine saubere, lineare Historie priorisiert, kann das Rebasen von Feature-Branches auf main vor dem Mergen dies erreichen. Dies erfordert jedoch die strikte Einhaltung der Regel, keine gemeinsamen Branches zu rebasen.

Szenario: Aktualisieren Ihres Feature-Branches mit Upstream-Änderungen

# Angenommen, Sie sind auf Ihrem 'feature'-Branch und 'main' hat neue Commits
git checkout main             # Wechseln zu main
git pull origin main        # Sicherstellen, dass main aktuell ist
git checkout feature        # Zurück zu Ihrem Feature-Branch wechseln
git rebase main             # Ihre Feature-Commits auf dem neuesten main wiederholen

Nun basiert Ihr feature-Branch auf dem neuesten main, und wenn Sie schließlich feature zurück in main mergen, wird es ein Fast-Forward-Merge sein (kein Merge-Commit erforderlich, wenn seit Ihrem Rebase keine neuen Commits zu main hinzugefügt wurden).

Szenario: Bereinigen Ihrer lokalen Commits (Interaktives Rebase)

# Angenommen, Sie haben mehrere kleine Commits auf Ihrem Feature-Branch gemacht
git checkout feature-branch-name
git rebase -i HEAD~3      # Die letzten 3 Commits interaktiv rebasen

Dies öffnet einen Editor, in dem Sie pick, reword, edit, squash, fixup oder drop für Ihre Commits auswählen können, um sie zu einer aussagekräftigeren Gruppe zusammenzufassen.

Best Practices und Warnungen

• Rebasen Sie keine gemeinsamen/öffentlichen Branches: Das Rebasen von Branches, die andere bereits gezogen und auf die sie ihre Arbeit gestützt haben, führt dazu, dass deren Historie von Ihrer abweicht. Verwenden Sie git merge für öffentliche oder gemeinsame Branches, es sei denn, Ihr Team hat einen expliziten Force-Push-Workflow.
• Rebasen Sie auf Ihren eigenen Branches: Rebase ist hervorragend für Ihre lokalen, privaten Feature-Branches geeignet, um sie sauber und aktuell zu halten. Sobald Sie mit Ihren lokalen Änderungen zufrieden sind, können Sie sie in einen gemeinsamen Branch mergen.
• Verstehen Sie die Auswirkungen: Bevor Sie git rebase ausführen, stellen Sie sicher, dass Sie verstehen, dass es die Historie umschreibt. Wenn Sie unsicher sind, ist git merge immer die sicherere Option.
• Berücksichtigen Sie den Workflow Ihres Teams: Besprechen Sie mit Ihrem Team, welche Strategie (Merge vs. Rebase) bevorzugt wird oder was Ihr definierter Workflow vorgibt.
• Saubere Historie ist wichtig: Während git merge die Historie bewahrt, kann eine Historie voller vieler kleiner, unbedeutender Merge-Commits unübersichtlich werden. git rebase kann helfen, eine sauberere, lesbarere Historie zu erstellen, insbesondere für Feature-Branches, bevor sie gemergt werden.

Fazit

Verwenden Sie git merge, wenn die Bewahrung der gemeinsamen Historie wichtig ist. Verwenden Sie git rebase, um Ihren eigenen lokalen Branch zu aktualisieren oder zu bereinigen, bevor andere davon abhängig sind. Wenn Sie unsicher sind, ob jemand anderes seine Arbeit auf Ihren Branch gestützt hat, mergen Sie anstatt zu rebasen.