I have a very simple setup. A feature gets developed in a feature branch and then gets squash merged into develop and with enough features ready we want to do a merge commit to master. All of this should happen via pull requests. The idea behind this is to hide all the details of the individual commits that would end up in develop/master behind the feature itself.
Currently, it seems not possible to actually enforce different merge types on different branches as described here: Set pull request merge options per branch
Even more importantly - is this actually a good strategy? Most of the people working with this are new to Git (including me) so I want to make this as easy and fail-safe as possible. I could not find any information on this after a googling for the last couple of hours.
So, I guess my question is: What is an easy way or maybe the best way to set this up? Do others have the same problem? If so - how do they solve it? Or is this a question that stems solely from not understanding GitHub well enough?
Any advice, documentation, or best practices you can point me too?
GitHub lets you adjust merge strategies per repository, not per branch. You can enable or disable certain strategies only for the entire repository.
However, you can disable rebasing globally and then require a linear history, which will mean that the only option is to squash merge. That doesn't, however, prevent you from accidentally squash merging into the wrong branch when you wanted a merge commit.
My general strategy is never to squash merge. While it tidies history, it also prevents Git from detecting merge bases for the squash merges (because no actual merge commits are created), so it can result in more conflicts than usual. Also, since many novice Git users choose to reuse the same branch again and again (for reasons unknown to me), this leads to bizarre repeated history and weird conflicts. The answer to the latter is, of course, to use a new branch for each feature, but that's difficult to explain to users.
If you care strongly about a clean history, then require that in code review; otherwise, it's probably fine to just live with an untidy history. The former is required by Git and the latter is the strategy used internally at GitHub; both are valid.
You can also just require users to squash their own history before using a regular merge commit, which is a strategy I've seen elsewhere. That gets you the tidiness and ease of use of squashing, without all of the downsides of squash merging. That's as easy as doing git reset --soft develop and then writing a commit message.