Git interactive rebase — squashing and editing commits

Interactive rebase is a history cleanup tool used immediately before opening or updating a PR — during development you commit freely, but the commits reviewers see should tell a coherent story about what the feature does.

The typical workflow

• git rebase -i origin/main opens the interactive editor listing every commit since the branch diverged; commits are shown oldest-first, opposite of git log
• Mark well-scoped commits as pick and everything else as fixup — fixup squashes the commit into the previous pick without preserving its message; squash lets you combine and edit the message
• The goal: three to five logical commits where each represents one complete idea — the domain model, the service layer, the controller — so reviewers can step through the feature's evolution rather than a stream of "WIP" and "fix null check"

Safety practices

• Always use --force-with-lease instead of --force when pushing after a rebase — it checks that no one pushed to the remote branch while you were rebasing; bare --force silently overwrites any commits they added
• Never interactive-rebase a branch that others have checked out — replaying commits produces new SHA1 hashes, making the remote branch incompatible with any local checkout based on the original SHAs
• Set rebase.autoSquash true globally — then git commit --fixup creates a commit that interactive rebase automatically places and squashes below the referenced commit

Advanced: splitting a commit with `edit`

• Mark a commit as edit to pause the rebase at that point; run git reset HEAD^ to unstage everything, then recommit in separate logical units
• Useful when a rename and a behavior change were accidentally committed together — splitting them makes git bisect pinpoint bugs more precisely and makes git blame more informative