Everyone wants to be indispensable until they don’t. Getting people to plant two years ahead is an eternal struggle.

I want a meaningful commit history, that actually enables me to find the useful commit message. My coworkers often create PRs where the branch itself contains merges and a lot of bad commits that are not centered around a single piece of functionality or activity (like formatting, refactoring).

I try to have them clean it up but often the best thing I can get is a squash.

I defend atomic PRs and squashing merge commits.

It's simple, makes reviewing easier and works for 90% of the cases.

Maybe I'm missing something, but I find it painful to rebase into a neat history, and my colleagues would probably hate me to police them around to do it as well.

PRs should be small units of change. PRs should be the edit history. If your process involves one PR per feature this makes them large and unwieldy, hard to review, hard to test, and more likely hard to rollback.

I commend your attempts to do CI and PRs at the same time, but most places have too high PR friction to make that work.

So it becomes a fight between the two.