Assuming PRs and associated feature branches are substantial[0], I'm a proponent of merging w/o squashing commits. When running `git bisect` or simply doing archaeology on a code base where the previous author(s) left the organization, I've never regretted reading granular commits--only too coarse.

[0] Largely depends on the team's workflow and the functional size of feature branches. If there are a lot of smaller commits made to develop/main/etc., then you can probably get away with squashing.

Squash and merge, to keep the commit history clean. You can always dig up the PR to see commit by commit how it happened if you must. We've only done this in my organization... maybe twice in five years. Personally I don't work elegantly enough that my commits represent some coherent narrative anyway, and it hasn't caused enough issues in my job for me to change my ways now.