100% agree, if you have multiple commits to complete the change during development, just squash them into one for the PR.
That being said many companies (including some FAANG) use commit counts as a performance metric, thereby directly disincentivizing clean, readable commits.
Re:The ideal PR is 50 lines long
by mandelbrotwurst on Wednesday February 07, 2024 @03:59PM
(#39294256)
Sure, and at the same time a PR can contain multiple commits. You don't have to squash and merge.
I've rarely seen cases where multiple commits per PR are a good thing. When that happens, it's (usually) that either the commits can be squashed into one logical/consistent commit, or there are too many changes for one PR.
The exception being that many ci/cd setups will squash your commits for you when merging a PR.
I feel that in the last decade somehow there has been a loss of context of what is the purpose of version control.
Why do we bother with version control? Sure, there are many reasons.
But a primary reason is that if we discover behavior X turns out to cause regressions (or is otherwise a bad idea), we can easily revert it by reverting its commit.
That's a why a single commit should contain a single behavior change, and contain the entirety of that single behavior change.
If the change is split among multiple commits, it'll be a pain to revert it. If the change is contained within a commit that changes other things, it'll be an ever larger pain to revert it.
So that's my rule. A commit is single behavior change, all of it, and nothing else.
You can't express that in lines. Might be 1 line might be lots.