I want clean history, but that really means (a) clean and (b) history.
People can (and probably should) rebase their private trees (their own work). That’s a cleanup. But never other peoples code. That’s a “destroy history”
So the history part is fairly easy. There’s only one major rule, and one minor clarification:
- You must never EVER destroy other peoples history. You must not rebase commits other people did.
[…]
If you are working with git together with other people, it’s worth a read.
That kind of commit quality should only really be permissible on private projects, and as a reviewer, it’s arguably acceptable to reject PRs with this kind of history.
You should be writing your commits to the benefit of the code reviewer - structure them in a logical fashion to tell the story about the changes you want to get merged.
For non-trivial branches I usually soft reset to the point where all code is unstaged and uncommitted and then curate the commits to align with what the reviewer should be reading. It’s not uncommon for me to have several branches containing a single “wip”-commit which I amend onto while building up the full code for the branch.