Git Rebase für Einsteiger: Eine einfache Einführung

Einführung

Falls Sie schon einmal auf Ihre Git-Historie geblickt und gedacht haben „das ist ja ein einziges Durcheinander”, sind Sie nicht allein. Diese verworrenen Branch-Linien und redundanten Merge-Commits erschweren es zu verstehen, was tatsächlich geändert wurde und wann. Hier kommt git rebase ins Spiel—ein mächtiges Werkzeug, das Ihnen hilft, eine saubere, lesbare Commit-Historie zu pflegen.

In diesem Leitfaden lernen Sie, was Rebasing bewirkt, wie es sich vom Merging unterscheidet und wann Sie es in Ihrem täglichen Workflow einsetzen sollten. Wir konzentrieren uns auf praktische Beispiele, die Sie sofort anwenden können, und beleuchten gleichzeitig die wichtigsten Fallstricke, die es zu vermeiden gilt.

Was ist Git Rebase?

Stellen Sie sich git rebase als das Umschreiben der Geschichte vor—aber im positiven Sinne. Beim Rebasing nehmen Sie Commits von einem Branch und spielen sie auf einem anderen Branch ab, als hätten Sie Ihre Arbeit von einem anderen Punkt aus begonnen.

Stellen Sie sich vor, Sie schreiben eine Geschichte. Sie beginnen mit Kapitel 3, während Ihr Kollege noch Kapitel 2 bearbeitet. Wenn er fertig ist, könnten Sie entweder:

• Mergen: Eine Notiz hinzufügen, die besagt „hier wurden die Änderungen von Kapitel 2 des Kollegen eingefügt”
• Rebasen: Ihr Kapitel 3 so umschreiben, als hätten Sie es begonnen, nachdem Kapitel 2 bereits fertig war

Der Rebase-Ansatz liefert Ihnen eine sauberere Erzählung ohne das „Merge-Rauschen”.

Warum Git Rebase verwenden?

Historie linear und sauber halten

Eine lineare Historie liest sich wie ein Buch—ein Commit folgt dem anderen in einer klaren Reihenfolge. Das erleichtert es:

• Nachzuvollziehen, wann Bugs eingeführt wurden
• Die Entwicklung von Features zu verstehen
• Code-Änderungen in Pull Requests zu reviewen

Ohne Rebasing füllt sich Ihre Historie mit Merge-Commits, die wiederholt „Merged branch ‘main’ into feature-xyz” sagen und dabei die tatsächlich geleistete Arbeit verschleiern.

Wann Entwickler Rebase wählen

Entwickler greifen in zwei Hauptsituationen zu rebase:

1. Aktuell bleiben: Ihr Feature-Branch benötigt die neuesten Updates von main
2. Arbeit polieren: Sie möchten Commits aufräumen, bevor andere sie reviewen

Beide Szenarien helfen dabei, die saubere, lineare Historie zu pflegen, die allen das Leben erleichtert.

Git Rebase vs Merge: Die wichtigsten Unterschiede

Hier ist der grundlegende Unterschied:

Merge erstellt einen neuen Commit, der zwei Branches kombiniert:

A---B---C (main)
     \   \
      D---E---M (your-feature)

Rebase spielt Ihre Commits auf dem Ziel-Branch ab:

A---B---C (main)
         \
          D'---E' (your-feature)

Beachten Sie, wie rebase neue Commits erstellt (D’ und E’), während merge einen Merge-Commit (M) hinzufügt. Das Rebase-Ergebnis ist linear und sauber, während merge die exakte Historie bewahrt, aber Komplexität hinzufügt.

Häufige Anwendungsfälle für Git Rebase

Ihren Feature-Branch aktualisieren

Sie arbeiten an einem Feature, während Ihr Team Updates zu main pushed. Um deren Änderungen zu integrieren:

git checkout your-feature-branch
git rebase main

Dies spielt Ihre Commits auf dem neuesten main ab und hält Ihren Branch aktuell, ohne Merge-Commits.

Commits vor einem Pull Request aufräumen

Bevor Sie Ihre Arbeit teilen, möchten Sie vielleicht Ihre Commits aufräumen. Interaktives rebase ermöglicht es Ihnen:

git rebase -i HEAD~3

Dies öffnet einen Editor, in dem Sie können:

• Mehrere „Work in Progress”-Commits zu einem zusammenfassen (squashen)
• Commits für logischen Ablauf neu ordnen
• Commit-Nachrichten zur Klarstellung bearbeiten

Zum Beispiel, dies:

- Fix typo
- WIP: add login
- More login stuff
- Fix tests

In das verwandeln:

- Add user login functionality with tests

Wichtige Warnungen: Wann Sie NICHT rebasen sollten

Die goldene Regel: Keine geteilten Branches rebasen

Führen Sie niemals rebase auf Branches aus, an denen andere arbeiten. Wenn Sie rebasen, erstellen Sie neue Commits mit unterschiedlichen SHA-1-Hashes. Falls jemand anderes die alten Commits hat, wird Git verwirrt und erstellt doppelte Commits.

Sicher zu rebasen: Ihr lokaler Feature-Branch
Niemals rebasen: main, develop oder jeden Branch, den andere verwenden

Force Push Risiken verstehen

Nach dem Rebasing müssen Sie oft force pushen:

git push --force-with-lease origin your-feature-branch

Das --force-with-lease Flag ist sicherer als --force, weil es prüft, dass niemand anderes Änderungen seit Ihrem letzten Pull gepusht hat. Trotzdem sollten Sie nur force push auf Branches anwenden, die Ihnen gehören.

Erste Schritte mit Git Rebase

Hier ist ein einfacher Workflow zum Üben:

1. Erstellen Sie einen Feature-Branch von main
2. Machen Sie einige Commits
3. In der Zwischenzeit wird main aktualisiert
4. Rebasen Sie Ihren Feature-Branch:

   git checkout feature-branch
   git rebase main

5. Falls Konflikte auftreten, lösen Sie sie und fahren Sie fort:

   git add .
   git rebase --continue

Beginnen Sie mit Ihren lokalen Branches, um Vertrauen aufzubauen, bevor Sie etwas Geteiltes rebasen.

Fazit

Git rebase ist ein mächtiges Werkzeug zur Pflege sauberer, linearer Commit-Historien. Indem Sie Commits abspielen anstatt zu mergen, erstellen Sie eine lesbarere Projekthistorie, die Ihrem gesamten Team zugute kommt. Denken Sie an die goldene Regel—rebasen Sie nur Branches, die Sie nicht gepusht haben oder die andere nicht verwenden—und Sie vermeiden die häufigen Fallstricke.

Beginnen Sie heute mit dem Üben an Ihren Feature-Branches. Sobald Sie die Klarheit einer linearen Historie erfahren haben, werden Sie sich fragen, wie Sie ohne sie gearbeitet haben.

Häufig gestellte Fragen

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.