Interactive rebase is the commit editor
git rebase -i <base> opens an editor with one line per commit between <base> and your current HEAD. You edit the lines to instruct Git: keep this commit, drop that one, reorder these two, squash these together, edit the message of that one, stop and let me amend that one. When you save and exit, Git replays the commits according to your script. The result: a different shape of history that ends at the same content (or a different content if you edited).
The verb at the start of each line is the instruction. pick keeps the commit as-is. reword keeps the changes but lets you rewrite the message. edit stops the rebase at that commit so you can git commit --amend with arbitrary changes, then git rebase --continue. squash folds the commit into the previous one, combining messages. fixup is squash but discards the fixup commit's message. drop deletes the commit entirely. Reordering lines reorders commits; deleting a line equals drop.
The most useful patterns: clean up a feature branch before merge with git rebase -i main — squash WIP fixes into their parent commits, drop the experimental detour, reword vague messages. Restructure ten commits into three logical units. Edit a months-old commit to drop a now-embarrassing log line: git rebase -i <hash>~1, mark the target with edit, fix it, git rebase --continue.
Two safety facts. Rebase rewrites history. The commit hashes change. If those commits were pushed and others used them, you have a coordination problem. Rebase is reversible. Until you push, git reset --hard ORIG_HEAD rewinds to before the rebase. Even after, the reflog has the pre-rebase tip for 90 days. Mistakes during interactive rebase are loud (Git stops on conflicts) and recoverable (reflog) — making it one of the safer "powerful" Git operations.