In every decent team project I've worked before (that had PRs in place), the merge strategy was to squash all commits into a single one, to be done into the master branch.
In the beginning, it felt odd, as "all my hard work and organized commits" would become a single, standardized blob of sorts. Then I got used to the flow and, well, whatever, right? It works®.
But then it came the time it was me who was deciding the path a team would start to walk through. And the question came, why squash merges? Why rebases?
As people say, first you resist, then you accept, and then you question what was happening.
So, to help with understanding why I chose Squash Merge to be the default for our repository:
Squash merges are usually preferred not only because of the "flat history" (that is usually easier to navigate with any tooling), but actually, because the history gets much cleaner and "straight to the point", without all the partial commits that are common during development.
If the squash is done correctly, you'll still maintain all commits' text in the squashed commit, so you can still get some details about the development of that feature, without clogging your master history.
One should also remember history is not only used to see code progress on a timeline/tree, but also for blaming changes. Even though you can use tools or extra options to "ignore" partial commits, blame probably won't - or will get too convoluted, at least.
I did some quick research to see discussions on the subject, and I can link you to two references that show my opinion and that I used to enhance my arguments above:
Answer about squash preference, on a CLI tool for Git Workflow:
[...] And over time, that's all we really care about in the history. Who made this change and why was it made. Squash merging allows us to do that while still giving all of our developers the individual freedom to develop in the way that suits them best.
GitHub manual about PR merge strategies:
You can use squash and merge to create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. If you squash these commits into one commit while merging to the default branch, you can retain the original changes with a clear Git history.
(this was also posted to my Medium)
Best wishes of no-conflict merges!