Gitlab has this very useful merging strategy for pull requests. This is an excerpt from their docs:
Semi-linear history merge requests
A merge commit is created for every merge, but the branch is only merged if a fast-forward merge is possible. This ensures that if the merge request build succeeded, the target branch build will also succeed after merging.
It would be trivial to implement: you could completely reuse your code for "rebase and then merge", just add the `--no-ff` option.
Can you consider this?
Thanks for this feedback! We're always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion we receive. I've logged your feature request in our internal feature request list. Though I can't guarantee anything or share a timeline for this, I can tell you that it's been shared with the appropriate teams for consideration.
I would also very much like this, I've spent a few hours investigating several options, and while there are some options with GitHub Actions (namely manually rebasing a feature branch using https://github.com/marketplace/actions/automatic-rebase before merging) there is nothing to enforce that.
Therefore first class support for semi-linear PR merging would be greatly appreciated.
Also the fact that another Microsoft Product - Azure Repos - supports a semi-linear merging strategy (not to mention *cough* GitLab) means I'm somewhat hopeful this feature may make its way to GitHub in the not too distant future.
Could anyone from GitHub provide an update on this maybe? 😁