Interactive Rebase & History Cleanup

A branch with nine commits called "wip", "fix", "fix again" and "actually fix" is a branch nobody wants to review. Interactive rebase turns that into three commits that read like a decision log.

Why This Module Matters

Commits serve two audiences. While you work, they are save points — cheap, frequent, and named whatever you were thinking at the time. Once the branch goes up for review, they become documentation, read by a colleague who was not there.

Those two purposes are in direct conflict, and interactive rebase is how the conflict is resolved. You commit sloppily and often while working, then, before anyone sees the branch, you rewrite it into the history you wish you had produced.

This matters to QA twice over. Your own bug-reproduction branches and test-automation branches get reviewed like any other code. And when you later use git bisect in Module 6, the quality of the history you are searching decides whether the answer is "this commit broke it" or "one of these nineteen files did".

What You'll Learn

• Opening the rebase todo list with git rebase -i HEAD~5 and reading it correctly (oldest first)
• squash versus fixup: combining commits with or without keeping the messages
• reword for a bad message, drop for a commit that should never have existed, edit for splitting one
• Reordering lines to group related work together
• Recovering when a rebase stops mid-flight: --continue, --skip, --abort
• Why --abort is always available and always safe

Pro Tip

Clean the branch before you open the Pull Request, not after. Rewriting history that reviewers have already commented on detaches their comments from the lines they were about.