Cleaning up a branch before review

Goal

Present a branch as a sequence of coherent commits that a reviewer can read one by one, without "fix typo" and "wip" noise and without behaviour changes hidden inside refactorings.

Prerequisites

A topic branch that has not been shared for others to build on, and a clean working tree.

Steps

1. While working, commit freely; mark corrections with git commit --fixup <commit> so that they can be folded automatically later.
2. Before review, run git rebase -i --autosquash <integration-branch>; reorder, squash and reword in the editor list.
3. Split commits that mix concerns (edit in the list, then git reset HEAD^ and re-commit in parts).
4. Run the tests after the rebase; a reordered sequence can break intermediate commits, which matters for bisecting.
5. Force-push with --force-with-lease to your own branch only.

Expected result

Every commit builds and passes tests on its own, has a message that explains why, and touches one concern; the reviewer can review commit by commit or as a whole.

Limits and test basis

Do this only on branches nobody else has based work on. Very long branches are better split into several reviews than polished as one. Mechanics follow the cited chapter.