Isn't that what the develop branch in Git Flow is for? Your project might need some additional steps as part of its release process, and those can take place using the corresponding release branch, but the idea is that you can start a new release off develop whenever you want.

I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. This gives you linear history.

Indeed. We're talking about using Git. Even if you're using a Git Flow style of workflow, why wouldn't you regularly rebase any feature branches back onto develop if they're lasting more than a short time, so you are keeping up-to-date, and why wouldn't you squash the finished feature down to a single commit that can be fast forwarded onto develop when it's ready, to maintain a linear history with one commit for one significant feature or fix?

The only time I've seen non-FF merges in a Git Flow style project is for bug fixes on release branches, but those tend to be characterised by two key properties: they are relatively simple and relatively important. If it's not simple, you probably need to abort that release and go back to your main development line to do whatever more substantial work is required before continuing, then make a new release. If it's not important, you probably ship that release with the known bug, and the fix gets made on the "develop" branch via the usual process for incorporation in future releases. So the effort involved in merging bug fixes from release branches back to develop is typically both relatively small and well justified, and if you do need any manual conflict resolution, that implies divergence since the point when the release branch was started and then it probably is a good idea for someone to take a more careful look and make sure the bug is properly fixed on develop as well.