Support Rebase+Merge (No FF) Pattern

[james-world]

Feature Request: Support for "Rebase-before-merge-commit" Pattern

... also known in ADO and GitLab as "Semi-Linear Merge", which is a cool name, but less clear regarding the underlying structure proposed.

Motivation

The rebase-before-merge-commit pattern yields a clean, linear history in main while preserving clear PR boundaries:

• Each PR contributes exactly one merge commit to main.
• The merge commit marks the PR boundary; the PR’s own commits live on its side branch.
• git log --first-parent shows a readable high-level history, and you can still drill down into a PR’s commits when needed.

Examples:

# Clean high-level history of PR merges on main:
git log --first-parent

# Show only the commits introduced by a PR whose merge commit is M2:
# (Assuming the previous merge commit on main is M1)
git log --no-merges <M1>..<M2>

# Inspect the merge commit's parents (first parent = previous main tip):
git rev-parse <M2>^1   # previous merge on main
git rev-parse <M2>^2   # PR branch tip

---

Problem

GitHub currently offers three merge strategies: Merge commit, Squash merge, and Rebase and merge.

The first two are already well understood for the problems they create presenting history in an intelligible way, but the one that most often gets considered as a "linear history" option is Rebase and merge. However, it drops merge commits entirely — losing the “one commit per PR” structure.

---

Diagram Comparison

Existing: Rebase and merge

main (first-parent):    *---*---*---*---*---*---*---*---*
PR A commits:                a1--a2--a3
PR B commits:                        b1--b2
PR C commits:                               c1--c2--c3

• The PR commits are rebased directly onto main.
• The history is linear but there are no merge commits.
• This erases the clear boundaries between PRs — you can’t tell from history alone where one PR ended and another began.

---

Desired: Rebase-before-merge-commit

main (first-parent):    M1-------------------M2-------------------M3-------------------M4
                         |                    |                    |
PR A (M1..M2):           \--a1--a2--a3--------/
PR B (M2..M3):                                \--b1--b2------------/
PR C (M3..M4):                                                     \--c1--c2--c3-------/

• Each M* is a merge commit whose first parent is the previous merge on main.
• main is a perfectly flat, linear chain of merge commits (git log --first-parent).
• Each merge commit M cleanly encapsulates one PR, while still pointing to the detailed commits on its side branch.

---

Enforcement Needs

To make this viable on GitHub:

1. Require PRs to be up to date with the base before merging.
   (Use “Require branches to be up to date before merging.”)

2. Enforce merge commits (no fast-forward) and preserve PR boundaries.

   • Ability to enforce non-fast-forward merge commits for PRs.
   • Optionally allow repos to disable squash and disable rebase-and-merge so this pattern is guaranteed.

---

Support in other Products

This feature, also known as Semi-Linear Merge is supported in ADO and GitLabs:

• https://devblogs.microsoft.com/devops/pull-requests-with-rebase/#semi-linear-merge
• https://docs.gitlab.com/user/project/merge_requests/methods/#merge-commit-with-semi-linear-history

Request

Add first-class support for the rebase-before-merge-commit workflow, either as:

• A new merge strategy, or
• Enhancements to “Merge commit” that enforce non-fast-forward semantics and pair well with “Require up-to-date before merging.”

Outcome:

• main has a readable, linear history of PR merges.
• Each PR is represented by one merge commit for auditability and release notes.
• The full detail of PR commits is still preserved and accessible.

[mas663]

Love this pattern. You can get ~90% of “rebase-before-merge-commit” on GitHub today with a few settings and a light workflow, even if there isn’t a first-class strategy yet.

Settings (repo → Settings):

• Pull Requests: disable “Squash merge” and “Rebase and merge,” keep “Merge commit” on.
• Branch protection (main): turn on “Require branches to be up to date,” require CI checks, and keep “Require linear history” off (you need merge commits).
• Optional: enable Merge Queue so PRs auto-update and merge in order.

Workflow:

• Rebase your PR branch onto the current main locally, resolve conflicts, then git push --force-with-lease.
• Maintainer uses “Create a merge commit.” You get a flat first-parent chain of M1, M2, M3 on main, each M* encapsulating exactly one PR.

Enforcement gaps today:

• “Update branch” in the UI performs a merge, not a rebase. For strict rebase-only, add a required status check that fails if the PR contains merge commits, e.g.:
  git fetch origin main && test -z "$(git log --merges origin/main..HEAD)"
• There’s no PR-scoped “non-FF only” toggle, so the combo above (disable squash/rebase, require up-to-date, merge-commit only) is the closest.

Feature request:

• A first-class “Rebase-before-merge-commit” strategy that (a) enforces rebase onto base, (b) forbids merge commits in the PR branch, and (c) always produces a non-FF merge commit on main. This pairs cleanly with Merge Queue and keeps git log --first-parent perfectly linear while preserving PR boundaries.

[YashSmithh]

Rebase + Merge (no fast-forward) isn’t directly supported by all platforms. Most UIs only offer Merge commit, Squash merge, or Rebase and merge. To enforce a “Rebase + no-FF” flow, you’d typically need to handle it locally with Git and push the branch.

[KailashSatkuri-warangal]

This is a great feature request — thanks for documenting it so clearly.

Current State on GitHub

• GitHub supports three strategies today:
  1. Merge commit (keeps history but not necessarily linear)
  2. Squash merge (linear but no PR boundaries)
  3. Rebase and merge (linear but drops merge commits entirely)

None of these fully replicate the rebase-before-merge-commit (aka semi-linear merge) workflow.

Workarounds Today

• You can approximate this pattern manually:
  1. Require branches to be up to date before merge (via branch protection rules).
  2. Locally git rebase main before merging.
  3. Use a merge commit (no fast-forward).
• This ensures that main is linear and each PR results in a merge commit, but enforcement is currently manual.

Why First-Class Support Would Help

• As you pointed out, semi-linear merge keeps both auditability (one merge commit per PR) and readability (linear history).
• GitHub’s current strategies force a trade-off between these two goals.
• Adding a dedicated merge strategy (or extending the existing “merge commit” option with stricter enforcement) would make this workflow consistent across all contributors without manual rebasing.

Related Implementations

• Azure DevOps: Semi-linear merge
• GitLab: Merge commit with semi-linear history

Suggested Next Step

The best way to move this forward is to open an issue in the official GitHub Feedback repo here:
👉 https://github.com/orgs/community/discussions/categories/github-feedback

If you share this request there, GitHub product managers can triage it and consider it for future roadmap updates.

---

[froh]

yes, yes, yes!

it would already be a great improvement if we can just disable "Update with merge commit" from the github web ui when Keeping your pull request in sync with the base branch.

for now we have to work around after the fact, by blocking merge to main if it contains merges itself... that gives not only a poor user experience. it also leads to doubling validation. because after the final rebase, you have to revalidate, after all...