Git Rebase setzt die Commits eines Branches auf eine neue Basis (englisch base) — meist die Spitze des Hauptzweiges — neu auf. Statt eines Merge-Commits (siehe Git Merge) entsteht eine lineare Historie: Die eigenen Commits wirken so, als wären sie direkt nacheinander auf dem aktuellen Stand des Hauptzweiges entstanden.
Wie Rebase funktioniert
Git nimmt die Commits des eigenen Branches, „hängt sie ab“ und spielt sie auf der neuen Basis erneut ein. Da sich dabei Zeitstempel und Commit-IDs ändern, schreibt Rebase die Geschichte um:
git switch feature/login
git rebase main # Feature-Commits auf main-Spitze neu aufsetzen
git rebase -i HEAD~3 # interaktiv: Commits umsortieren, squashen, umbenennenBeim interaktiven Rebase stehen Kommandos wie pick, reword, edit, squash, fixup und drop zur Verfügung — damit lassen sich mehrere kleine „WIP“-Commits vor dem Teilen zu einem sauberen Commit zusammenfassen.
Merge oder Rebase?
Die Faustregel: Rebase für lokale, unveröffentlichte Arbeit; Merge für gemeinsame Branches. Wer öffentliche Commits umschreibt (etwa auf main), zwingt alle anderen per git push --force zum Aufräumen — das ist im Team gefährlich. Moderne Workflows kombinieren beides: erst rebasen, dann mergen, damit der Merge garantiert als Fast-Forward durchläuft und die Historie linear bleibt.
git pull --rebase # lokale Commits auf neue Remote-Spitze setzen statt Merge-Commit
git push --force-with-lease # nur wenn eigene Branch-Spitze verifiziert (Vorsicht!)Praxis-Tipps
- Rebase nur auf Branches, an denen niemand anderes arbeitet.
- Vor einem Rebase mit Konflikten:
git rebase --abortmacht alles rückgängig. - Squashen vor dem Repository-Push hält die gemeinsame Historie lesbar.
Verwandte Grundlagen: Git Branch, GitFlow, git-Befehle.