Wow, the first thing I do when creating a new repo is disable fast-forwarding, especially for large teams.
The merge commit is the quickest way to see all the changes that came in from a branch, and if you do branching right, all the changes related to a particular feature by one developer.
Also, merge commits are much easier to roll back, no matter how rarely you need it.
Another option, used by large teams at Facebook, is to only use fast-forwarding but squashes all branch commits. You can still roll-back a merge, but your master's revision history is still linear (for what that's worth).
This is how I prefer to handle PRs, too. `git merge --squash pr-branch`. Prevents the history from turning into an indecipherable tangle of branches, and prevents tons of "fixing typo," "code review feedback," "more code review feedback," "adding back file" kinds of commits from taking over the history.
You can rebase commits in your feature branch as well and clean up the history. Having separate and small commits also helps in blaming and looking at the history do figure out why a certain change is in there.
If you squash all the commits you probably should summarize all the commits into that single commit message which is also work if done properly.
In the end it's preference and how your developers create commits and documment them.
The merge commit is the quickest way to see all the changes that came in from a branch, and if you do branching right, all the changes related to a particular feature by one developer.
Also, merge commits are much easier to roll back, no matter how rarely you need it.