Set Squash&Merge / Merge commit restrictions in Branch Protection Rules

[rschock-outside]

🏷️ Discussion Type

Product Feedback

Body

Like a lot of people, we use a feature (optional) > release > main workflow. We generally want all PRs merged into feature/release initially to be Squash & Merge. Later if a feature is going into a release, we want it to be a Merge commit (to not lose history and tracking). Likewise for release into main, these should always be a Merge commit to not lose history and tracking.

It would be great if in the Branch Protection rules that we could override the system wide Settings for these merge types so the github UI would only allow the the ones we want based on the target. Even more powerful would be to the ability to specify these in not just a "into" sense but also a "from"/"to" for the feature > release use case. Right now we have informal rules for the engineers to follow but they frequently forget and merge the wrong way and we lose history and tracking.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[initial-d]

This is mostly possible now with rulesets, although not as an old-style Branch Protection override.

The important distinction is:

• Repository Settings -> Pull Requests controls which merge methods are globally enabled for the repository.
• A branch ruleset can then restrict the merge method allowed for the branches targeted by that ruleset.

So I would keep the needed merge methods enabled globally, then add separate branch rulesets, for example:

1. Target feature/* and require pull request merge method = squash.
2. Target main and require pull request merge method = merge commit.
3. Target release/* and require merge commit if every PR into release should preserve branch history.

Docs: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

The rule is listed under the pull request rules: “Require a merge type of merge, squash, or rebase.” The related changelog is here too: https://github.blog/changelog/2024-12-04-pull-request-merge-method-rule-public-preview/

One caveat for your exact from/to matrix: rulesets are mainly target-branch based. They are good for “anything into main must be a merge commit” or “anything into feature/* must be squash.” They do not fully express “if source branch matches feature/* and base branch matches release/*, require merge commit, otherwise require squash” as a single native UI rule.

For that part, I would combine rulesets with one required status check. A small workflow can inspect github.base_ref and github.head_ref on pull_request and fail if the selected/expected path is wrong. For example:

name: merge-policy

on:
  pull_request:
    types: [opened, synchronize, reopened, edited, ready_for_review]

jobs:
  merge-policy:
    runs-on: ubuntu-latest
    steps:
      - name: Validate source/target branch policy
        run: |
          base='${{ github.base_ref }}'
          head='${{ github.head_ref }}'

          if [[ "$base" == "main" && "$head" != release/* ]]; then
            echo "Only release/* branches should merge into main."
            exit 1
          fi

          if [[ "$base" == release/* && "$head" != feature/* ]]; then
            echo "Only feature/* branches should merge into release/* through this path."
            exit 1
          fi

Then require that status check in the ruleset for main / release/*.

That still cannot read the user’s final button choice before merge in every case, so for the actual merge-method enforcement I would use the native ruleset merge-method rule wherever the policy is target-branch based. For source+target routing, use the required check to stop the wrong branch-flow before people get to the merge button.

[spenserblack]

Agreed, especially with

Even more powerful would be to the ability to specify these in not just a "into" sense but also a "from"/"to" for the feature > release use case.

Maybe I'm missing something, but I haven't seen any way to set a restriction based on the source branch. Sometimes hotfixes get merged directly into main, master, production, release/*, etc., and then those hotfixes get moved to a development branch with a main -> development-branch PR. That main -> development-branch PR should definitely not be squashed or rebased, as that creates one or more new commits instead of merging the existing commits. All "typical" PRs (features and low-priority bug fixes) could continue to be merged into development-branch via squash or rebase.

[initial-d]

Yes, I think that is exactly the remaining gap.

The native ruleset merge-method rule is useful when the policy is based on the target branch:

anything -> main        must use merge commit
anything -> release/*   must use merge commit
anything -> develop     must use squash/rebase

But it does not currently express a full source+target matrix like:

feature/* -> develop       squash allowed
main -> develop            merge commit required
hotfix/* -> main           merge commit required
release/* -> main          merge commit required

For that kind of policy, the closest enforceable workaround I know is:

1. Use rulesets for the target-branch cases that are always true.
2. Add a required workflow check that inspects github.head_ref and github.base_ref and blocks disallowed branch flows.
3. For flows where preserving exact commits matters, document/use the GitHub CLI or API merge method explicitly, for example gh pr merge --merge, because the workflow can block the PR but cannot fully change which merge button the user clicks.

A required check can prevent the worst mistakes, for example blocking main -> development-branch unless the PR is marked as a backport/sync PR:

name: branch-flow-policy

on:
  pull_request:
    types: [opened, edited, synchronize, reopened, labeled, unlabeled]

jobs:
  branch-flow-policy:
    runs-on: ubuntu-latest
    steps:
      - name: Validate branch flow
        run: |
          base='${{ github.base_ref }}'
          head='${{ github.head_ref }}'
          labels='${{ join(github.event.pull_request.labels.*.name, ",") }}'

          if [[ "$base" == "development-branch" && "$head" == "main" ]]; then
            if [[ ",$labels," != *",backport,"* && ",$labels," != *",sync,"* ]]; then
              echo "main -> development-branch PRs must be labeled backport or sync and merged with a merge commit."
              exit 1
            fi
          fi

That still is not the same as a native “source branch + target branch + merge method” rule, because it cannot inspect the final merge button before the merge happens in all UI paths. So I agree with the feature request: a source/target-aware ruleset condition would close a real governance gap for release trains, hotfixes, and backport/sync PRs.