Suggestion: use a different branching/merging strategy (Oneflow)

We currently (as far as I recall/can tell) use a branching strategy based on this article: https://nvie.com/posts/a-successful-git-branching-model/

However, the way the master branch is being used feels a bit redundant in some ways/adds seemingly unnecessary commits (via --no-ff merges); to put it another way, I feel personally persuaded by this article (the branching history does look a tad messy): https://www.endoflineblog.com/gitflow-considered-harmful

So I suggest/propose we use this model instead: https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow

What this amounts to practically speaking for the most part, is that we would not do --no-ff merges onto master (or ever make any commits directly to it), we would merely fastforward it to the commit on dev that we consider to be the most recent release, and use master solely as a way to make sure the main branch people see when visiting the page is always on the most recent release. That's one variant of the strategy suggested there (listed under the heading "Variation – develop + master").

There is a more specific explanation of how to implement the branching strategy on Gitlab here: https://www.endoflineblog.com/implementing-oneflow-on-github-bitbucket-and-gitlab

There is also a recommendation to not use --no-ff for merging of branches onto dev either (using --squash merge instead), but I'm less certain of that being a good idea.