Is there a way to merge branches on GitHub via pull requests with different and enforced merge strategies?

user_828499 0
Viewed 646

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?

pull-request git-merge merge github git
2 Answers

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.

user_87054320

It is as you say possible to disable certain merge strategies, but that means you'll need admin priveleges to be able to use any other merge strategy than the ones that are enabled. It's also only configurable for the repository, and not for a branch, or as a default for new github organization repositories. Not a great solution by GitHub in my opinion. At least not on it's own. It would be much better if we were also allowed to choose which merge strategy to select by default, and still leave the other alternatives open.

Because this feature is lacking, and much needed, I went ahead and made a feature request for it: https://github.com/github-community/community/discussions/20583

Go take a look and comment and/or vote on it to share your opinion :)

user_122063120
Related