Git History Hygiene

Turn a 47-commit "WIP / fix / oops" feature branch into a reviewable sequence of well-named commits before it reaches a pull request. This skill is a discipline-driven playbook built entirely on the real git CLI: audit the branch, classify every commit, rewrite with interactive rebase, and verify the rewrite against a backup ref before pushing.

A messy commit history makes code review slow, blame archaeology painful, and git bisect useless. Git History Hygiene gives you a repeatable, safety-first workflow for rewriting a feature branch's history — squashing fixups, dropping dead ends, rewording messages — so the merged history tells the story of the change, not the story of how you fumbled through it.

• Before opening a pull request, when your feature branch has accumulated WIP commits, typo fixes, reverted experiments, and merge-noise.

• When a reviewer asks for a "clean history" on an existing PR.

• When you inherit a branch with dozens of commits and need to make it reviewable without losing any actual changes.

• Before merging a long-lived feature branch that contains debugging commits, commented-out code, or "trying again" commits.

• Never on main, master, develop, release branches, or any branch other people build on. Rewriting shared history is destructive and cannot be fully undone for collaborators.

• When the branch is already merged (rewrite the follow-up instead).

• When the PR is about to be squash-merged anyway — the platform will produce one clean commit and history cleanup adds nothing.

• When commits contain secrets or large binaries that must be purged from history entirely — that is a git filter-repo incident-response job, not history hygiene (see Limitations).

• When you are unsure whether anyone else is working from your branch — confirm first, rewrite second.