Interactive rebase (git rebase -i) ermöglicht es dir, Commits umzuschreiben, neu zu ordnen, zu kombinieren, zu bearbeiten oder zu löschen — und damit deine Commit-Historie zu bereinigen, bevor du sie teilst. Es ist ein mächtiges Werkzeug, um aus unordentlichen Work-in-Progress-Commits saubere, logische History zu schaffen.
git rebase -i HEAD~4
git rebase -i <commit>
pick abc123 Add login form # keep the commit as-is
squash def456 Fix typo # COMBINE into the previous commit (merge messages)
fixup ghi789 Fix another typo # combine into previous, DISCARD this message
reword jkl012 Add validation # keep the commit but EDIT its message
edit mno345 Refactor auth # PAUSE to amend the commit (change content)
drop pqr678 Debug logging # DELETE this commit entirely
# reorder lines to REORDER commits
Du bearbeitest die Liste — wählst für jeden Commit eine Aktion aus (und Zeilen umzuordnen ordnet Commits neu) — dann spielt Git sie entsprechend ab.
✓ SQUASH multiple WIP commits into one clean commit ("wip", "fix", "oops" → one good commit)
✓ REWORD bad commit messages
✓ REORDER commits into a logical sequence
✓ DROP unwanted commits (debug code, mistakes)
✓ SPLIT a commit (via edit) into smaller commits
→ Result: a clean, logical history instead of messy development commits.
⚠️ Interactive rebase REWRITES history (new commit hashes):
→ only do it on LOCAL, UNPUSHED commits — never on shared/public history
→ typical use: clean up your feature branch BEFORE pushing/opening a PR
Interaktives Rebase zu verstehen ist wertvoll für das Schaffen sauberer Commit-History, daher ist es praktisches Wissen für professionelle Git-Arbeit.
Während der Entwicklung sind Commits oft unordentlich — Work-in-Progress-Commits mit Meldungen wie „wip„, „fix typo„, „oops„, Debug-Commits und nicht-logische Reihenfolge — und interaktives Rebase ermöglicht es dir, dies vor dem Teilen zu bereinigen: mehrere unordentliche Commits in saubere logische zusammenfassen, schlechte Meldungen umformulieren, Commits in eine sinnvolle Reihenfolge bringen, unerwünschte Commits löschen (wie Debug-Code) und Commits aufteilen — unordentliche Entwicklungs-History in eine saubere, logische, überprüfbare Sequenz verwandeln.
Das ist wichtig, weil saubere Commit-History (wie in guten Commit-Praktiken beschrieben) Code Review erleichtert, History verständlicher macht und Debugging (via Bisect) effektiver macht — die Fähigkeit, vor anderen alles aufzuräumen, ist daher ein Zeichen professioneller Git-Praxis.
Die Aktionen (pick, squash, fixup, reword, edit, drop und Umordnung) und häufige Anwendungsfälle (besonders das Zusammenfassen von WIP-Commits, ein sehr häufiges Bedürfnis) zu verstehen, ist die praktische Fertigkeit.
Entscheidend ist, dass die goldene Regel des Rebase immer noch gilt — interaktives Rebase schreibt History um (neue Hashes), daher darf es nur auf lokalen, nicht hochgeladenen Commits gemacht werden (nie auf gemeinsamer History), wobei der typische Anwendungsfall das Bereinigen eines Feature-Branch vor dem Hochladen oder Öffnen eines Pull Request ist.
Da saubere, logische Commit-History wertvoll für Zusammenarbeit und Wartbarkeit ist, und da Entwicklung natürlicherweise unordentliche Commits produziert, die interaktives Rebase vor dem Teilen bereinigen kann (sicher, auf lokalen Commits), ist das Verstehen von interaktivem Rebase — die Aktionen, häufige Anwendungsfälle wie Squashing und die Sicherheitsregel — wertvoll, praktisch relevantes Git-Wissen für professionelle Entwicklung, ein mächtiges Werkzeug zur Präsentation sauberer, überprüfbarer History, das nachdenkliche Git-Nutzer auszeichnet, routinemäßig zur Verfeinerung von Arbeit vor dem Teilen mit dem Team verwendet.