Pull request merge method rule public preview - feedback

[patrick-knight]

You can now enforce what merge method is available on a specific branch with the new pull request merge method rule in public preview.

Choose between Merge, Squash or Rebase and ensure only selected merge methods are supported.

Learn more in the documentation

Video example of enabling the rule

GitHubScreenShot-Arc-04-12-2024-004121.mp4

Known issues

Conflicting merge methods between the repository setting and the rule will cause merges to fail.

Feedback

We want to hear from you! Add your comments, questions, likes and dislikes below. 🔽

[DzmVasileusky]

@patrick-knight Sorry but can you share a nav path to this feature? I checked all the tabs in repository settings including General and Branches but couldn't find it.

[tdorianh]

I found it via:
Settings -> Rules -> Rulesets -> (edit or create a branch ruleset) -> Branch rules -> Require a pull request before merging -> Show additional settings -> Allowed merge methods

[patrick-knight]

@DzmVasileusky I added a video example to the post above.

[freakyblack]

Did you have trouble finding the navigation path to this feature?

[gebeto]

@freakyblack here ya go

Screen.Recording.2025-01-31.at.17.40.05.mov

[CrazyMeal]

This is great news 🥳 !
Do you have an idea about when it might be available through the rulesets API so then in Terraform provider ? 👀

[patrick-knight]

PR is going up soon to add it to the API docs, but the endpoint is live now.

      "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 0,
        "dismiss_stale_reviews_on_push": false,
        "required_reviewers": [],
        "require_code_owner_review": false,
        "require_last_push_approval": false,
        "required_review_thread_resolution": false,
        "automatic_copilot_code_review_enabled": false,
        "allowed_merge_methods": [
          "squash",
          "merge",
          "rebase"
        ]
      }
    }
  ],```

[ciaransweet]

Just came to ask the same! Any idea when the docs will get the update?

[ebinion]

Love it! Most of my initial use case was to manage staging versus production environments with Render, Netlify and the likes without having a CD. This should work perfectly.

[mathroule]

That's great news! Thanks for implementing this feature 🎉

This works well for one aspect of our workflow, but we still encounter a failing case.

Our workflow consists of the following steps:

1. Create a topic branch from the develop branch.
2. Merge the topic branch into the develop branch using "Squash".
3. Create a release branch from the develop branch.
4. Merge the release branch into the main branch using "Merge" (to keep Git history and keep main in sync with develop).
5. Create an apply-release-change branch from the main branch (to merge back changes from main into develop).
6. Merge the apply-release-change branch into the develop branch using "Merge".

Currently, we can only set up rule to allow "Squash" and "Merge" for merging branches into develop, regardless if it's a topic or an apply-release-change branch.

However, there is still an opportunity for developers to merge topic branch using "Merge" instead of "Squash." It would be beneficial to exclude the source branch from the ruleset, allowing us to establish rules like these:

• One ruleset that permits only "Squash" for merging into develop, except when the source branch is apply-release-change.
• Another ruleset that allows only "Merge" for merging into develop, except when the source branch is not apply-release-change (i.e. when it's a topic branch).

[phillipuniverse]

I’ve got the exact same case as you @truls1502, well said!

[truls1502]

@patrick-knight, do you have any idea when we will be able to test this feature with strategies for the "target" and "source" branches?

[patrick-knight]

@truls1502 We do not currently have plans at the moment for that specific functionality.

[truls1502]

Ok, please let us know when this is planned and ready to test 😊

[warmfire540]

how are you handling merge commits? we ask devs not to MERGE w/ the button in higher environments and instead use a command to run a fast forward. This prevents those terrible commit messages into staging/prod only

[Snailedlt]

I would like to see an option to set the default merge method per branch as well, as discussed in this discussion (or more specifically here) there are times where you want to "nudge" contributors towards using a certain merging method without enforcing it. Choosing which merge method is default is one way to do that.

[patrick-knight]

Noted and thanks for continuing to advocate for that option here. I should have been more clear in my earlier response to you in the other discussion this is a way we start addressing this problem space not nessicarily the only or final one. But I want to ensure this preview does the job and then we can iterate from here.

[DzmVasileusky]

Agree, it gives flexibility.
One of the possible use cases:
Standard feature/branch approach with develop, staging, master and feature-[n]
We want Squash be the primary (default) method for develop for cleaner git history but sometimes we need Merge commit.
Imagine you have feature-1 which wasn't merged yet and your colleague started to work on feature-2 which needs feature-1 code.
In this case you need to merge feature-1 with a Merge commit if you don't want conflicts and noise in the feature-2 PR

[TharunMJ]

Do you think setting a default merge method per branch would improve your workflow?

[charpeni]

There's a typo in the changelog:

The merge method rule is availible for rulesets at the repository, organization and the enterprise level.

availible -> available.

[patrick-knight]

🙈 Thanks just resolved that.

[Reunt]

Does spotting a typo in the changelog affect your user experience, or do you see it as a minor issue?

[edwardyoung]

@patrick-knight is it possible to bypass this setting to fall back to the merge methods allowed at the repo level? For example, I would want developers to only squash (set in a rule) to the dev branch while allowing members of the DevOps team to have the option to use merge or squash (set at the repo level).

[patrick-knight]

Not yet, we currently do not have bypass support built-in but once that is available you should be able to craft a rule like that.

[patrick-knight]

We just added in the ability to bypass this rule and so that should now be working as expected. Please let me know one way or the other.

[edwardyoung]

Hi @patrick-knight thanks for this! I did notice one issue when testing the bypass feature.

In my test repo settings, under Pull Requests we allow merge commits and squash merging.

I set up a branch rule targeting our default branch where the only thing checked off is "Require a pull request before merging" and the only thing set under additional settings is "Allowed merge methods" is set to Squash.

If I test this rule as is, I'm getting the expected results. On a pull request, the only merge method available is Squash. If I add myself to the bypass list, I do see both merge commits and squash merging options but if I choose merge commit, I get an error saying "The develop branch requires linear history".

Now if I disable the rule and go back to my PR, I'm able to choose merge commit without getting the error saying "The develop branch requires linear history". Would you know why this is happening? I double checked my rule and "Require linear history" is not checked off.

Thanks!

[patrick-knight]

Hey @edwardyoung,
Is there the possibility a branch protection rule is also in place on the same branch setting this requirement?

[edwardyoung]

Hi @patrick-knight ,

There is a branch protection rule but "Require linear history" is not checked off. That's the setting I would be looking for right?

[Haarolean]

Bypassing a ruleset with the merge method rule enabled doesn't work, the ruleset is still applied fully to a person included in the bypass list.
I aimed to allow everyone squash merge and rebase only for maintainers.

[patrick-knight]

That is currently a limitation that we are working in remedying

[patrick-knight]

We just added in the ability to bypass this rule and so that should now be working as expected. Please let me know one way or the other.

[Haarolean]

@patrick-knight this does work indeed now, thanks very much!

[raffadh28]

Have you encountered a similar issue where bypassing a ruleset didn’t work as expected?

[sarah-gelt]

This is perfect for our team - we want to allow squash or merge in our dev branch, with only merge being allowed in staging and main. Now configured and looks great! 🙌

[heidimhurst]

Our exact same use case - we'd been wanting to enforce this for ages, but after a particularly bad mishap were happy to find this preview and give it a go! 🙏

[warmfire540]

how are you handling merge commits? we ask devs not to MERGE w/ the button in higher environments and instead use a command to run a fast forward. This prevents those terrible commit messages into staging/prod only

[tc23]

What do you think is the best way to instruct developers to avoid using the merge button in staging and production?

[travi]

I would like the ability to add conditions to the rule.

For the use case I'm interested in, I want to enforce a merge method that does not rewrite the history of the branch being merged when it is a (pre)release branch (in the context of a library). This would help avoid mistakes when a project values maintaining provenance between versions published to the registry, the source commits they resulted in, and the versions that follow them. In semantic-release, release channels are aligned with branches and default conventions include support for alpha and beta branches as pre-release branches.

I would like to leave the merge method flexible for normal feature contributions, but limit the merge method when the source branch being merged into the target branch that the rule is related to is a release branch. Ideally, I would supply a list of branch names to the rule that limits the merge type and would expect that the rule could be defined even if some of the named branches do not currently exist.

[patrick-knight]

Hey @travi,

Is this similar to the asks in this thread? Where depending on the source a different behavior is applied? https://github.com/orgs/community/discussions/146284#discussioncomment-11465262

[codeflava]

Have you ever encountered a situation where rewriting the history of a merged branch caused serious issues?

[payaaam]

We have a rule that only allows "Merge" into our main branch. We are seeing an issue where this option shows "Not enabled for this repository"? There are no other repository rules that would conflict. I was wondering if we have something incorrectly configured?

[patrick-knight]

What are the pull request merge settings enabled on the repo? That might be in conflict with the rule.

https://github.com/<owner>/<repo>/settings

[payaaam]

Yep! That was it. Thank you

[gebeto]

Is it possible to configure it in the way so:

• development branch can be only merged with commit to main branch
• main branch can be only merged with commit to development branch
• any other branches can be squashed to main or development

I need this, to be able to force merge without squashing between main and development to keep whole history tracked, and be able to do some hotfix PRs with squash ability to main branch (when there are already some more changes in development branch and we need to merge hotfix right to the main branch, and then merge main branch to development to deploy that hotfix also to staging environment)

[patrick-knight]

This behavior was also mentioned in the thread here.

Currently there are no plans to address that behavior as part of this preview.

[xornews]

Do you know if there’s any current way to configure merge rules as you desire, or any external tools that can help?