You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, using the "rebase and merge" option on a pull request will merge the branch using the fast-forward option. This is sometimes called a "linear history" model. The semi-linear model would be equivalent to rebasing the PR branch and then merge it as per the normal merge option (which always creates a merge commit, even if the merge could be fast-forwarded).
The motivation for this model is described in several places, of which I'd highlight A tidy, linear Git history. I took the liberty to slightly edit the diagram from that post, to add a pure linear workflow to the diagram. I think this conveys nicely the differences between merge vs. rebase && merge --ff-only (linear) vs. rebase && merge --no-ff (semi-linear):
Of course, such a workflow can be implemented via the command line, or using third-party tools, but since GitHub already supports multiple merge strategies (merge, rebase and merge, squash), it seems sensible to natively support this additional option in the web UI.
(originally reported in isaacs/github#1017)
Currently, using the "rebase and merge" option on a pull request will merge the branch using the fast-forward option. This is sometimes called a "linear history" model. The semi-linear model would be equivalent to rebasing the PR branch and then merge it as per the normal merge option (which always creates a merge commit, even if the merge could be fast-forwarded).
The motivation for this model is described in several places, of which I'd highlight A tidy, linear Git history. I took the liberty to slightly edit the diagram from that post, to add a pure linear workflow to the diagram. I think this conveys nicely the differences between
merge
vs.rebase && merge --ff-only
(linear) vs.rebase && merge --no-ff
(semi-linear):Of course, such a workflow can be implemented via the command line, or using third-party tools, but since GitHub already supports multiple merge strategies (merge, rebase and merge, squash), it seems sensible to natively support this additional option in the web UI.
FYI, GitLab has already implemented this, and it's been requested for Bitbucket as well (in #12914 and #17881, as well as several comments in #6106).
The text was updated successfully, but these errors were encountered: