> Squash is fine on balance, but it's not zero effort. If you branch a new feature off a branch that gets squashed it will usually cause annoying conflicts.
Conflicts happen when multiple people work on code, squash or no-squash.
The benefit of squash is when (not if) you want to solve a conflict, you only do it once. You get to compare the final snapshot of your code and the final snapshot of their code, and decide on a single, new best version.
This is in contrast to solving a conflict where you replay 10 of your commits against 10 of their commits, and try to work out what 'theirs' and 'mine' means as you change the same constructor from 2 args to 3 args 10 times.
Squash is fine on balance, but it's not zero effort. If you branch a new feature off a branch that gets squashed it will usually cause annoying conflicts.
This is usually fine if you merge frequently (ideal, but not always possible) but if you don't then it can quickly become very irritating.
If I joined a project which was fearful of deployments and frequently had backed up branches then I wouldn't be in a hurry to force them to start using squashes until after that problem was solved.
>You want to split it in multiple commits? Then it probably should have been split in multiple PRs .
Should is absolutely the wrong way to think about pretty much all software engineering practices. Add up the costs and the benefits.