W3docs

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.

An interactive rebase todo list squashing and rewording commits

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~3

Git 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 tweaks

You 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

ActionShortEffect
pickpUse the commit as-is.
rewordrUse the commit but edit its message.
editePause at the commit so you can amend its content.
squashsCombine into the previous commit, merging both messages.
fixupfLike squash, but discard this commit's message.
dropdRemove the commit entirely.
reorderMove 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 tweaks

When 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 --continue

To abandon the whole rebase and return to where you started:

git rebase --abort

A 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

Practice

Which statements about interactive rebase are correct?