git rebase -i (interactive)
Learn interactive rebase with git rebase -i to squash, reword, edit, drop, and reorder commits before sharing them. Includes a command reference.
Definition
Interactive rebase, run with git rebase -i, lets you rewrite a series of commits before you share them. It opens an editable "todo list" of commits where you decide, line by line, what happens to each one — keep it, reword its message, fold it into another, split it, reorder it, or drop it. It builds on plain git rebase but puts you in control of every step.
Starting an interactive rebase
Point the command at the commit before the first one you want to edit. To revisit the last three commits:
git rebase -i HEAD~3Git opens your editor with one line per commit, oldest at the top:
pick a1b2c3d add login form
pick b2c3d4e fix typo
pick c3d4e5f more css tweaksYou change the word at the start of each line to choose an action, then save and close. Git replays the commits according to your instructions.
The todo-list commands
| Action | Short | Effect |
|---|---|---|
pick | p | Use the commit as-is. |
reword | r | Use the commit but edit its message. |
edit | e | Pause at the commit so you can amend its content. |
squash | s | Combine into the previous commit, merging both messages. |
fixup | f | Like squash, but discard this commit's message. |
drop | d | Remove the commit entirely. |
reorder | — | Move lines up or down to change commit order. |
Squashing commits together
A common cleanup is folding several small commits into one. Mark the first as pick and the rest as squash (or fixup to drop their messages):
pick a1b2c3d add login form
squash b2c3d4e fix typo
fixup c3d4e5f more css tweaksWhen you save, Git combines the three into a single commit and lets you write a clean message.
Finishing or bailing out
If a step causes a conflict, Git pauses so you can resolve it. After staging the fixes, continue:
git rebase --continueTo abandon the whole rebase and return to where you started:
git rebase --abortA word of caution
Interactive rebase rewrites history — the resulting commits have new hashes. That is perfect for tidying up your own branch before opening a pull request, but never rebase commits that others have already pulled. Rewriting shared history forces everyone else to reconcile divergent copies. The golden rule: rebase locally, merge publicly.
Practice
Which statements about interactive rebase are correct?