Just to comment on your last paragraph - I don't really understand people's obsession with having squashed commits on main. I may not have a local copy of the branch that was merged months ago, so I can't get the un-squashed history without jumping through hoops. It also makes tools like git-bisect much less useful.
With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged into mainline wholesale, without any further squashing.
Each commit has the ticket id in the commit message, so you can find all related changes easily if ever needed. This gives us history that's both granular enough to be useful, and meaningful.
(Granted, if your team is disciplined enough to only have very small and granular PRs that only deliver a small logical unit of change at a time, the distinction between approaches becomes moot... but in my experience most PRs tend to be a little bigger that that, and contain at least a couple of related but distinct sets of changes)
And yeah, the commit history in this project is just hilarious.
> With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged ...
A lack of this simple discipline is what causes people to push for squashing. If you squash every PR then your commits may be too coarse, but you don't end up with random "fix tests" commits everywhere. If it's not part of your company culture to do the cleanup then it's harder to get that rolling than to just impose a repo rule that only squash merges are allowed in.
With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged into mainline wholesale, without any further squashing.
Each commit has the ticket id in the commit message, so you can find all related changes easily if ever needed. This gives us history that's both granular enough to be useful, and meaningful.
(Granted, if your team is disciplined enough to only have very small and granular PRs that only deliver a small logical unit of change at a time, the distinction between approaches becomes moot... but in my experience most PRs tend to be a little bigger that that, and contain at least a couple of related but distinct sets of changes)
And yeah, the commit history in this project is just hilarious.