Disable "Squash and merge" on some specific branches

[makotoshimazu]

Hi,

I'm now building a deploy workflow for a monorepo, and trying to set up a CI workflow triggered by a push to a special branch (like production) for deployment. We currently merge regular PRs to the main branch using "Squash and merge" by enabling "Require linear history" option, and merging "deploy" PRs to the production branch with "Create a merge commit" in order to avoid unexpected divergent.
It works, but not perfect because "Squash and merge" button is present when merging a PR to the production branch.
As far as I searched, I couldn't find a good way to enforce developers to use "Create a merge commit".

Is there a good way to achieve that?
So far, I could find a stackoverflow saying it's not possible.

Thanks in advance!

[whatbird]

+1. same exact use case.

there are so many options in the "Branch protection rules" I was surprised this wasn't one of them (and also it seems like a good place to hang this feature)

[jackhodkinson]

+1

We want to enforce Squash and merge going into master and then we create a Release PR from master into production which we want to enforce Create a merge commit. Currently there is no way to do this. Furthermore, the "default" option presented to the user when approving a PR depends on the last selected Merge type. This means accidents happen a lot where we Squash and merge into production. This is a big problem because the next time we try to merge master into production there are merge conflicts.

We have resorted to using memes to try to get everyone to remember to apply the right merge type for the right branch:

Merging into prod be like:

[xmo-odoo]

We have resorted to using memes to try to get everyone to remember to apply the right merge type for the right branch:

FWIW the actual solution is probably to swear off github's merge button and use automated integration (whether via github workflows or an external tool). As long as humans need to perform contextual optional actions (in the sense that there is no way to set the merge button as not having a default method, so you can always click the button and it'll do something) there will be errors.

[rjohnsonbade-dcs]

Haha thanks I'm stealing this for our docs.
We're in exactly the same position, pretty common for anyone following anything close to GitFlow.
I'd also love it if we could god damn fast-forward commit, makes no sense why we cant configure this basic stuff.

I used the azure product briefly and it had much better customisation of this stuff.

[san1t1]

I done wrote this.

https://github.com/san1t1/github-squash-merge-preventer-chrome-extension

[Matthew0x]

"Furthermore, the "default" option presented to the user when approving a PR depends on the last selected Merge type. This means accidents happen a lot where we Squash and merge into production"
That's terrible. I had the exact same issue and observation.

"I used the azure product briefly and it had much better customisation of this stuff."
Yes, it is possible to select the merge type precisely with Azure DevOps. It's very difficult to justify the lack of this option with GitHub.

[Abdelilah301]

I fixed the issue you test it I think its working
and you can remove the reload from if you want
https://github.com/Abdelilah301/squash-merge-preventer

[SatheeshJM]

+1

This seems like a pretty normal use case.
I'm surprised more people are not complaining about this.

[proftom]

me too

[miszo]

+1

I really would like to set merging strategies per branch – same way as it is possible now for the whole repository. For benchmark: Azure Repositories does it really well. Other things are far worse, but this is where they're superior in my opinion.

[timoaudi]

+1

Our team would like to configure merge strategy for each branch separately as well

[jzavgok]

We have the same use case as some users above and we run into the same issues in our business unit. We really need an ability to set merge strategies per branch(s), ideally in-branch protection rules rather than for the whole repo.

[jimmcslim]

Yes, this keeps biting us as well. GitHub... please hear our cries!

[jimmcslim]

Or at least some response from GitHub about why this is not possible or recommended? 🤷

[Matary1]

ok

[auditect]

Branch protection rules appears to be the right place to define this. Github, please reach out if you are looking for beta testers for this feature request. ;-)

[makotoshimazu]

Thanks a lot those who showed interests in this feature request!
FWIW, we created a GitHub Action which simply creates and merges a deploy PR, that can be triggered manually. I know it's a bit tedious and ugly, but it's an only solution we came up to prevent from using "Squash and merge" accidentally until this feature request is resolved.

[miszo]

Hi @makotoshimazu, can you share the source code of the GitHub Action?

[makotoshimazu]

I hope this helps:
https://gist.github.com/makotoshimazu/7d0e2ab1301760521b1cd9bdded4be7b

[garytryan]

This would be a great feature. The number of times people on our team accidentally squash merge to master, then I'm forced to resolve conflicts on develop...urgh!
Please GitHub consider this feature! :)

[mgslone]

It persists the button as whatever last one you used, which makes this really easy to flub. Then the poor sucker who has to do the next merge into the deploy branch has a mess to unravel.

[rbedellasmgroup]

Seriously, the merge type dropdown should persist by target branch, not across all branches.

[JakubHylaScalable]

Yeah, this feature would be great.

[shinshinwu]

yes please allow specify merge strategy per branch protection rule...

[rjohnsonbade-dcs]

Seems so simple, it is a form of protecting the branch anyway.

[rohan-sca]

+1 exact same use case. Surprising that it hasn't been considered for so long.

[romandvoskin]

+1. We've been promoting branches associated with environments so dev->stg->prod and it would be great to enforce squash merge into dev and disable squash merge for stg and prod.

[ajgrande924]

+1 need this

[cavalluccijohann]

+1

[jberclaz]

+1

[rabie-sulman]

+1

[bcrantsequoia]

+1

[thesuperzapper]

In the interest of getting an official response from GitHub, I am tagging the leadership team: @ashtom, @mariorod

I imagine they lose customers every day to GitLab because of this very issue.

What is the issue?

Users need to restrict what kinds of PR merge are allowed depending on the target branch, not as a global repo setting like it currently is.

How can it be fixed?

Simply add a branch protection rule setting that allows restricting the PR merge type.

User Story 1

Millions of people use GitHub branches to represent deployment environments.

They want the following:

1. PRs into dev branch must be "Squash and Merge"
2. PRs from dev -> test must be "Create a Merge Commit"
3. PRs from test -> prod must be "Create a Merge Commit"

This ensures that each commit in each environment has the same hash, while also preventing bedlam in the dev branch from people who don't understand what squashing is.

User Story 2

Many people use "staging" branches to test multiple features/changes before mering into main.

They want the following:

1. PRs into staging/* branches must be "Squash and Merge"
2. PRs from staging/* into main must be "Create a Merge Commit" or "Rebase and Merge"

This ensures that PRs into main are able bring multiple commits (that is, multiple features that were all tested in the same staging branch), while also preventing the staging branches becoming a mess from people who don't know about squash commits.

[vinay0x]

+1

[patrick-knight]

Thanks for all the feedback here, I really appreciate it.

We’ve been discussing this topic for a while and how to address this with repository rules as the way to limit which merge methods are available per branch.

We’ll be back soon to share a link to a new public roadmap item for this with details around timing and the plans to address this gap.

[mskreativ]

@patrick-knight : I'm very much looking forward to get the new feature soon. Thanks a lot.
Next to the "allowed merge types" per ruleset it's requested to be able to define a default merge type on target branches as well, see: https://github.com/orgs/community/discussions/20583
Are you working on this as well, and going to combine it together in rulesets (which may interfere) or more in a "branch protection rule"?

[sraka1]

@patrick-knight is there a tentative date when this will go into public beta yet? Thanks :)

[patrick-knight]

We're targeting this Wednesday 12/4.

[carlosalban]

+1 on being able to define a default merge type on a branch

[patrick-knight]

This new PR merge method rule is rolling out now in preview.

Please direct your feedback about the behavior and configuration in this new discussion post: https://github.com/orgs/community/discussions/146284

[anthonwellsjo]

+1

[victorezzer]

+1

[Maaxion]

+1

[sharmadhiraj]

I know it's better to have this feature in the backend, but for anyone okay with a frontend solution to avoid mistakes when merging PRs, I've built an extension. I use squash for all branches except when merging into master, but sometimes I make mistakes in the process.

The extension lets you customize settings for repos, source/destination branches, and merge options. Feel free to check it out, and I'd appreciate any feedback or suggestions!

https://chromewebstore.google.com/detail/github-pr-merge-strategy/nhejampjhfhnalboieehcfhehmmfljhg

[dirablue]

@sharmadhiraj
This is very useful. thank you 🙂

[samuel-baena-stenn]

+1

[SlavenBesevicMedorion]

+1

[evstropovv]

it's already resolved https://github.com/orgs/community/discussions/146284

[willsmythe]

Closing this out since this feature is generally available: https://github.blog/changelog/2025-03-24-enterprise-custom-properties-enterprise-rulesets-and-pull-request-merge-method-rule-are-all-now-generally-available/

Start a new discussion or use the preview feedback discussion to provide additional feedback: https://github.com/orgs/community/discussions/146284