Interactive rebase — cleaning up commits before sharing them

This is genuinely how commits often look while actively working — small fixes, typo corrections, "WIP" placeholders — none of which is a problem locally (from the daily-workflow and rebasing-vs-merging lessons, this only matters once it's shared). Before opening a pull request or merging this into main, though, this history is exactly the kind of noise the daily-workflow lesson's "commit small, commit often" advice was never meant to produce — five commits telling a confusing story, when the actual change is one coherent thing: implementing a login form.

git rebase -i opens an editable list of the commits being replayed, oldest first, each with a command (pick by default) that controls what happens to it. This is the actual mechanism behind "cleaning up history" — instead of just replaying commits unchanged (plain rebase, from its own lesson), interactive rebase lets each one be reworded, reordered, combined with its neighbor, or dropped entirely, before the replay actually happens.

Changing a commit's command from pick to squash or fixup merges it into the commit directly above it in the list — squash keeps both commit messages, combined, for editing into one final message; fixup discards the fixed-up commit's message entirely, keeping only the one it's being merged into. This is exactly how five commits — a rough start, the real implementation, and three small fix-up commits — become one clean commit: "Implement login form," with a single, meaningful message.

Marking a commit reword (instead of pick) pauses the rebase at that commit specifically to let its message be rewritten — the actual code changes stay completely untouched, only the message changes. This is the fix for "I wrote a bad commit message and want to improve it before anyone else sees it," without needing squash/fixup at all if the content itself is already fine.

Marking a commit drop (or simply deleting its line from the list) removes it from history entirely, as if it had never been made — genuinely useful for a commit that was itself a mistake (an experiment that didn't pan out, a debug print statement accidentally committed) rather than something to combine with a neighbor.

Since the list is just text, reordering commits is as simple as reordering the lines — the replay then happens in whatever order the list ends up in. This matters when commits would make more sense in a different order than they were originally made in, though it's worth noting that reordering commits that touch the same lines can introduce conflicts during the replay that didn't exist in the original order.

Interactive rebase is still rebase underneath — every commit it touches gets replayed as a new commit object with a new hash, the identical mechanism the rebasing-vs-merging lesson covered. The same hard rule applies without exception: this is for cleaning up commits that are still entirely local, before they're ever pushed and shared — running it on commits someone else has already pulled creates the exact same orphaned-work danger covered there.