[Feature Request] Semi-linear history merging strategy


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?




Hi @marton78,

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.

Ref: https://devblogs.microsoft.com/devops/pull-requests-with-rebase/

Could anyone from GitHub provide an update on this maybe? :grin:


This is another pain-point for us which we’re working around by manually rebasing PRs locally before merge.

I would love it if this would be actively considered for implementing, as I believe it would be very doable considering it’s already implemented in Azure Repos and GitLab.


Chiming in to say that my team is also looking forward to having this functionality that all your competitors seem to have.

It would help our work tremendously if GitHub had an option in pull requests to merge the PR with a semi-linear history, since we almost exclusively use a branching model with semi-linear history (mostly we use the stable mainline branching model).

The option could look like this:

Furthermore it would be very useful if the CI tests/pipelines of the PR were re-run for the rebased branch, before the merge commit is perfomed.


@belhfl just wanted to check-in to see if there is any update on this?

If you want to replace Azure Pipelines with Github at some point (which I’m guessing you will), it’ll make sense to add this feature to Github, since it’s already supported in Azure Pipelines (and also Gitlab and many others).

Thanks for making Github, it’s a great product! :medal_sports:

This feature is similar to what I want, which is to dissallow merges from base into child branches, but allow merges from children to base and also rebase on top of latest. Basically this: