Interactive Rebase
Interactive rebase (git rebase -i) replays a range of commits one at a time onto a new base, but pauses first to let you edit the plan: reorder commits, combine several into one, reword messages, split a commit apart, or drop it entirely. Unlike a plain rebase, which simply reapplies commits in their existing order, interactive rebase treats history as something you author deliberately rather than something that merely accumulates. It is the primary tool for turning a stream of 'wip', 'fix typo', and 'actually fix it this time' commits into a small number of coherent, well-described changes before a pull request is reviewed.
Cricket analogy: Instead of just replaying a batting innings ball by ball in order, interactive rebase lets a coach pause the tape to reorder passages of play, splice two similar-looking overs into one highlight, relabel a misdescribed shot, split a messy over into distinct clips, or cut a scrappy dot-ball sequence entirely before showing it to selectors.
The Rebase Todo List
Running git rebase -i HEAD~5 opens an editor containing a 'todo list': one line per commit, oldest first, each prefixed with a command word (pick by default). You edit this list, save, and close the editor; Git then executes it top to bottom. The commands you will use most are pick (keep the commit as-is), reword (keep the change but edit the message), edit (pause after applying so you can amend the commit), squash (fold into the previous commit and merge messages), fixup (fold into the previous commit and discard this message), and drop (remove the commit entirely). Reordering lines reorders commits, which is powerful but can produce conflicts if later commits depend on earlier ones in their original order. squash and fixup are the workhorses for day-to-day cleanup: a typical pattern is to make small, frequent commits while developing, then squash them into one logical commit before opening a pull request. fixup pairs especially well with git commit --fixup=<sha>, which creates a commit auto-prefixed fixup!; running git rebase -i --autosquash then automatically moves it next to its target and marks it for squashing, with no manual todo-list editing required.
Cricket analogy: A coach reviewing a training tape line by line marks each drill 'keep', 'relabel', 'pause-and-adjust', 'merge-into-previous-drill', 'merge-and-discard-label', or 'cut'; merging small warm-up reps into one clean session summary is the day-to-day workhorse before showing it to the squad, and a pre-tagged 'merge-with-last-drill' clip auto-attaches during review with no manual sorting.
# Rebase the last 5 commits on the current branch interactively
git rebase -i HEAD~5
# Example todo list Git opens in your editor:
# pick a1b2c3d Add password reset endpoint
# squash e4f5a6b Fix typo in reset endpoint
# reword 7c8d9e0 wip
# fixup 1f2a3b4 address review comment
# drop 9z8y7x6 debug console.log
# Create a fixup commit targeting an earlier commit, then autosquash it
git commit --fixup=a1b2c3d
git rebase -i --autosquash HEAD~6
# Rebase interactively onto another branch's tip
git rebase -i mainSplitting and Editing Commits
Marking a line edit stops the rebase right after that commit is applied, leaving your working tree in that exact state with the rebase paused. From there you can run git reset HEAD~1 to unstage the commit's changes while keeping the files modified, then re-stage and commit them in smaller pieces — effectively splitting one commit into several. Once satisfied, git rebase --continue resumes replaying the remaining commits. If a conflict occurs during any step, Git pauses the same way: resolve the conflict, git add the resolved files, and run git rebase --continue, or git rebase --abort to bail out and restore the branch to its pre-rebase state. Every one of these steps is local and non-destructive until the rewritten branch is actually pushed.
Cricket analogy: Pausing a training review right after a specific drill lets the coach freeze the squad in that exact drill state, break it into smaller focused reps, and resume the full session review afterward; if a disagreement arises mid-review, they resolve it and continue, or scrap the review and restart from the original plan.
Never interactively rebase commits that have already been pushed and that other people may have based work on. Rebasing rewrites commit hashes, so anyone who pulled the old commits will get diverging history and confusing merge conflicts on their next pull. It's safe on local, unpushed commits or on a private feature branch you alone own — always confirm before force-pushing a rebased branch.
Think of the rebase todo list as a recipe you write for Git to follow, not a live edit of the commits themselves — Git only touches history once you save and close the editor, and git rebase --abort at any point restores your branch exactly as it was before you started.
git rebase -i <base>opens an editable todo list of commits to reorder, squash, reword, edit, or drop.squashmerges a commit into the previous one and lets you edit the combined message;fixupdoes the same but discards the message.git commit --fixup=<sha>plusgit rebase -i --autosquashautomates targeting and squashing without manual reordering.- Marking a commit
editpauses the rebase so you can split it into smaller commits viagit reset HEAD~1. - Conflicts pause the rebase; resolve,
git add, thengit rebase --continue, orgit rebase --abortto cancel entirely. - Never interactively rebase commits that have already been shared with collaborators — it rewrites history and diverges everyone else's clone.
Practice what you learned
1. Which `git rebase -i` command folds a commit into the previous one while discarding its commit message?
2. What does marking a commit as `edit` in the rebase todo list do?
3. What command automatically moves and marks `fixup!`-prefixed commits next to their target during an interactive rebase?
4. Why is it dangerous to interactively rebase commits that have already been pushed and pulled by teammates?
5. During an interactive rebase, a conflict occurs. What is the correct sequence to resolve it and proceed?
Was this page helpful?
You May Also Like
Cherry-Picking Commits
Cherry-picking applies the changes from a specific commit made on one branch onto another, letting you selectively port individual fixes without merging entire histories.
Amending and Rewriting Commits
Amending lets you fix the most recent commit's message or contents without creating a new commit, while broader history rewriting tools reshape older commits before sharing them.
Rebasing vs Merging
Compare git rebase and git merge as two different strategies for integrating branch changes, and learn when a linear history is worth the trade-offs of rewriting commits.
git reset Explained
How git reset moves the current branch pointer and optionally rewrites the staging area and working directory, and the meaningful difference between its --soft, --mixed, and --hard modes.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics