Interactive rebase (git rebase -i) lets you rewrite, reorder, combine, edit, or drop commits — cleaning up your commit history before sharing it. It's a powerful tool for crafting clean, logical history from messy work-in-progress commits.
git rebase -i HEAD~4 # interactively rebase the last 4 commits
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
You edit the list — choosing an action per commit (and reordering lines reorders commits) — then Git replays them accordingly.
✓ 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
Understanding interactive rebase is valuable for crafting clean commit history, so it's useful practical knowledge for professional Git work.
During development, commits are often messy — work-in-progress commits with messages like "wip", "fix typo", "oops", debug commits, and a non-logical order — and interactive rebase lets you clean this up before sharing: squashing multiple messy commits into clean logical ones, rewording poor messages, reordering commits into a sensible sequence, dropping unwanted commits (like debug code), and splitting commits — transforming messy development history into a clean, logical, reviewable sequence.
This matters because clean commit history (as covered in good-commit practices) makes code review easier, history more understandable, and debugging (via bisect) more effective — so the ability to tidy up before others see your work is a hallmark of professional Git practice.
Understanding the actions (pick, squash, fixup, reword, edit, drop, and reordering) and common uses (especially squashing WIP commits, a very frequent need) is the practical skill.
Critically, the golden rule of rebasing still applies — interactive rebase rewrites history (new hashes), so it must only be done on local, unpushed commits (never on shared history), with the typical use being cleaning up a feature branch before pushing or opening a pull request.
Since clean, logical commit history is valuable for collaboration and maintainability, and since development naturally produces messy commits that interactive rebase can clean up before sharing (safely, on local commits), understanding interactive rebase — the actions, common uses like squashing, and the safety rule — is valuable, practically-relevant Git knowledge for professional development, a powerful tool for presenting clean, reviewable history that distinguishes thoughtful Git users, used routinely to polish work before it's shared with the team.