Contents

Engineering Craft › Version Control (Git)

Interactive Rebase

Rewriting commits: squash, reorder, edit, drop.

Also known as: git rebase -i, rebase interactive, squash commits, rewriting commits, fixup

git rebase -i (“interactive”) lets you edit a series of your own commits: reorder them, combine them, reword their messages, split them or drop them. It’s how you tidy a messy branch into a clean story before asking for review.

git rebase -i HEAD~4        # edit the last 4 commits

Git opens an editor with a list, oldest first:

pick a1b2c3d Add search endpoint
pick e4f5a6b WIP
pick 7c8d9e0 fix typo
pick 1f2a3b4 Add tests for search

You change the word at the start of each line:

CommandDoes
pickKeep the commit as it is
rewordKeep it, but edit the message
editStop at this commit so you can change its content, or split it
squashCombine into the previous commit, and edit the combined message
fixupCombine into the previous commit, discarding this commit’s message
dropRemove the commit

You can also reorder the lines. Save and close, and Git replays the commits accordingly. For example, turning WIP and fix typo into fixup leaves two clean commits.

A useful shortcut

git commit --fixup a1b2c3d      # mark a small correction for that earlier commit
git rebase -i --autosquash main # Git arranges the fixups automatically

Rules and risks

  • Only rewrite commits that you haven’t shared. Rebased commits get new hashes, so rewriting ones others have pulled causes real trouble. After rewriting commits you already pushed to your own branch, update with git push --force-with-lease (force push).
  • Conflicts can appear while replaying. Resolve and git rebase --continue, or git rebase --abort to go back to how things were.
  • Nothing is lost immediately: the reflog lets you recover the old state if you make a mistake.
  • Don’t make history so polished that it hides real steps. The aim is clear, reviewable commits (atomic commits).

See rewriting history and squash.