Post

Unpopular opinion: squashing commits when merging pull requests is a major mistake.

With each PR being one commit, and commits being single small, well-defined changes, you end up being led toward concluding that PRs should also be single small, well-defined changes which, despite GitHub marketing, is a Bad Idea that kills your productivity and helps your codebase rot.

Commits should be small, atomic, self-contained changes serving a single purpose. No argument there. Pull requests are just a bunch of work someone wants to merge. That's all. It is counterproductive to make them follow the same rules as commits because they're not commits.

We can probably agree that people should leave the codebase better than they found it. That means fixing little incidental annoyances as you go, and refactoring things to make your changes easier. The thing is...

Inevitably, your "real work" ends up depending on these little cleanup items. If you force each of these cleanup items to be its own PR, then you end up with a chain of interdependent PRs to be reviewed, which bogs everything down.

Just make PRs with a succession of commits. Craft your commits with care. Rebase until the commits look nice and reviewable. Then merge them with normal merge commits.