Default merge strategy (per org, repo or branch)

[Snailedlt]

Default Merge Strategy

Why we need it

In our GitHub organization we have a workflow where the preferred merge strategy is Squash and merge. Whenever we merge into master, we usually use this strategy. We would like to be able to set this as the default merge strategy, without removing the options for Create a merge commit and Rebase and merge for special occasions. Currently the only way to set Squash and merge is to disable the other options. This is problematic, since we sometimes need to merge using other merge strategies in special cases, for example if the PR closes multiple issues, and we want one commit per issue it solves. Another thing that makes this hard is that currently GitHub selects the merge strategy based on what you selected ln your last PR. This means that when an unusual option is selected, the user needs to remember to change it back to the "default" so that he/she doesn't accidentally merge with the wrong strategy on their next merge. This is a big source of user errors, and can lead to multiple hours spent trying to fix the (sometimes irreversible) mistakes done by choosing the wrong merge strategy. Instead of having the default be the last selected strategy, it should be possible for repository admins to select which merge strategy is defaulted to.

Suggested Implementations

1. Add an option in repository settings to choose the default merge strategy.
2. Add an option in branch resteictions, to choose the default merge strategy.
3. Add an option in the GitHub organization settings to choose the default merge strategy for any newly created repositories.

Additionally, if the GitHub UX team finds it useful, it would be nice to have the default merge strategy highlighted in the merge button dropdown. Either with a different background color, or an associated emoji to show if the merge strategy is a default in the org, repo or branch.

Implementations and other relevant links

Relevant Links

• Merge methods per branch #8196
• Organization defaults/templates for repositories (GitHub Enterprise) #13991
• GitHub Community“Squash and Merge” as default Pull Request merge option
• StackOverflow | Is there a way to specify a default option for merging a pull request in GitHub?

Implementations by GitHub alternatives

Bitbucket Cloud (My favourite)

Bitbucket Server

Gitlab

Gitea

Edit

A partial solution involving the ability to disable certain merge methods has been implemented using repository rules. The solution can be found here: https://github.com/orgs/community/discussions/146284, and is further discussed in this comment: https://github.com/orgs/community/discussions/20583#discussioncomment-11274521

Support for choosing a default merge method per branch still remains to be implemented.

[tyge68]

Make totally sense, +1 for such improvement

[gCardinal]

It would also be interesting to have the option for users to define a default strategy.

For example, if I work in multiple organisations and Org A defines "Fast Forward" as a default and Org B defines no default, if I set my default to "Squash" merging a PR in Org A would use "Fast Forward" as the strategy whereas merging a PR in Org B would use "Squash".

[Snailedlt]

Yes! Definitely would be useful to have default strategies per organization

[Myera2411]

Yes! Definitely would be useful to have default strategies per organization

[eyadmba]

A default strategy per branch is a good improvement, but I'd rather completely disable certain strategies with certain branches.

[Snailedlt]

That would be a great option too, but it doesn't replace the need for default merge strategies, as in some cases you want to squash merge, and in others you may want to rebase and merge, or merge normally

[katylava]

It's pretty annoying to not be able to have different merge strategies per branch. We have repos where we use a strategy of merging PRs into a develop branch, and to release we merge develop into main. We want to enforce squash merge from PRs into develop, but never squash merge from develop to main because then git gets very confused about what has already been merged.

[katylava]

Just learned this specific use case is covered in #8196. Be sure to upvote it if this is what you need as well!

[mskreativ]

+1

I need to define allowed and default merge method individually for some named branches.

[sobolk]

+1

[rahul1]

+1 - Very useful for open-source projects with multiple repos

[ivanwidj]

+1 - very useful for project with env specific branches

[ACBatconsumeraffairs]

+1 This would be very helpful to companies using different merging for lower environments than those used in the upper envs.

[shaiboujuappcharge]

• 1

[gunnsth]

+1. This is absolutely necessary. If I have master, release and develop. Then I only want to allow squash merge into develop (I usually like 1 commit per change rather than 50 or more, which gets messy imo). Rest needs to be regular commit. Otherwise the github compare mechanisms starting thinking there are missing commits and it does not work well.

[vinod-soni-microsoft]

+1

[ConnorCallison]

+1

[hq6]

+1

[fredericrous]

other relevant issue that is very similar to this one 👉 https://github.com/orgs/community/discussions/10809

[Snailedlt]

Let's link the two together: #10809

[DzmVasileusky]

+1

I think it would be pretty simple to implement since UI already has squash and rebase methods enforcing via branch protection.
We want linear strategy for the develop branch with squash but avoid noise and conflicts when merging hotfixes created from master in both branches

[neilsoult]

Please papa microsoft, before Lina Khan busts your monopoly
+1

[Myera2411]

Default Merge Strategy

Why we need it

In our GitHub organization we have a workflow where the preferred merge strategy is Squash and merge. Whenever we merge into master, we usually use this strategy. We would like to be able to set this as the default merge strategy, without removing the options for Create a merge commit and Rebase and merge for special occasions. Currently the only way to set Squash and merge is to disable the other options. This is problematic, since we sometimes need to merge using other merge strategies in special cases, for example if the PR closes multiple issues, and we want one commit per issue it solves. Another thing that makes this hard is that currently GitHub selects the merge strategy based on what you selected ln your last PR. This means that when an unusual option is selected, the user needs to remember to change it back to the "default" so that he/she doesn't accidentally merge with the wrong strategy on their next merge. This is a big source of user errors, and can lead to multiple hours spent trying to fix the (sometimes irreversible) mistakes done by choosing the wrong merge strategy. Instead of having the default be the last selected strategy, it should be possible for repository admins to select which merge strategy is defaulted to.

Suggested Implementations

1. Add an option in repository settings to choose the default merge strategy.
2. Add an option in branch resteictions, to choose the default merge strategy.
3. Add an option in the GitHub organization settings to choose the default merge strategy for any newly created repositories.

Additionally, if the GitHub UX team finds it useful, it would be nice to have the default merge strategy highlighted in the merge button dropdown. Either with a different background color, or an associated emoji to show if the merge strategy is a default in the org, repo or branch.

Implementations and other relevant links

Relevant Links

• Merge methods per branch #8196
• Organization defaults/templates for repositories (GitHub Enterprise) #13991
• GitHub Community“Squash and Merge” as default Pull Request merge option
• StackOverflow | Is there a way to specify a default option for merging a pull request in GitHub?

Implementations by GitHub alternatives

Bitbucket Cloud (My favourite)

Bitbucket Server

Gitlab

Gitea

[GSudeendra]

+1

[nam-truong-le]

+1

[DominicGBauer]

+1

[ssyberg]

+1

[patrick-knight]

TL;DR - Were working on it.

We are going to address this with repository rules as the way to limit which merge methods are available per branch.

More details here in the other discussion post https://github.com/orgs/community/discussions/10809#discussioncomment-10329765

[Snailedlt]

Awesome!
Would be nice to see another option for default branch too though. Some branches you want to squash and merge most of the time, but on occasion you might want to just merge normally.

For example you usually wanna have 1 PR per feature. In which case you name the PR with the name of the feature and squash merge it. But sometimes you may have features that depend on each other, where you want to merge them at the same time, but still keep the commits separate so that the automated changelog and release notes show all of the new features.

If this is the case for your repo you wouldn't want to deny normal merging, but you would like to have them make a conscious decision to do anything other than squash merging.

This is where the default merge type would be really handy!

[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

[sedsedus]

@patrick-knight
Repository rules are great, however, this doesn't address the main issue highlighted by the OP - which is the error-prone nature of the default selection (remembered from the last actual merge).
In my project, we sometimes have to merge (to the same branch) with squash, and sometimes without. So having a 1/0 kind of switch will not help us at all.

[merusso]

@Snailedlt , I suggest that you unmark this answer for now. If it's "answered", people will think this feature is now available, but the behavior you're asking for isn't yet available.

The GitHub feature enables a repo to restrict PR merge types. It doesn't offer a means to set a default merge type.

Thoughts?

[Snailedlt]

@merusso agreed. unmarked

[MichaelChirico]

I'm not 100% sure this is the exact issue for this feedback (since this seems to be mainly about "rebase" vs. "squash"), but it's at least similar.

One pain point I have is that my merge strategy (ort) on local works perfectly to resolve conflicts in our NEWS file, but GitHub's merge strategy always finds conflicts.

This is a pain because resolving conflicts wipes out reviewer Approvals, whereas conflict-free merges do not.

That means that on local, I can easily merge with no conflict, but on GitHub I have to invalidate review to proceed (generating lots of reviewer toil). And of course pushing the conflict-free merge from local also invalidates the review.

This is especially painful if I go on a productive streak and push 5-6 PRs, each of which touch the NEWS. It generates a tedious dance where reviewers have to continuously re-Approve PRs (n choose 2 --> a quadratically increasing number of approvals).

[MaxBeauchemin]

+1

[bleadof]

+1

[allan-wright-pushpress]

+1

[tdubourgR]

Not sure what reasons there would be not to implement this. This is currently causing a significant amount of wasted time in my team, not to have a selectable default, due to various devs having different workflows.

[conditionsofexistence]

+1

[jonas-singe-bruker]

+1