Default merge strategy (per org, repo or branch) #20583
-
Default Merge StrategyWhy we need itIn our GitHub organization we have a workflow where the preferred merge strategy is Suggested Implementations
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 linksRelevant Links
Implementations by GitHub alternativesBitbucket Cloud (My favourite) |
Beta Was this translation helpful? Give feedback.
Replies: 128 comments 22 replies
-
|
Make totally sense, +1 for such improvement |
Beta Was this translation helpful? Give feedback.
-
|
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". |
Beta Was this translation helpful? Give feedback.
-
|
Yes! Definitely would be useful to have default strategies per organization |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
A default strategy per branch is a good improvement, but I'd rather completely disable certain strategies with certain branches. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Just learned this specific use case is covered in #8196. Be sure to upvote it if this is what you need as well! |
Beta Was this translation helpful? Give feedback.
-
|
+1 I need to define allowed and default merge method individually for some named branches. |
Beta Was this translation helpful? Give feedback.
-
|
+1 - Very useful for open-source projects with multiple repos |
Beta Was this translation helpful? Give feedback.
-
|
+1 - very useful for project with env specific branches |
Beta Was this translation helpful? Give feedback.
-
|
+1 This would be very helpful to companies using different merging for lower environments than those used in the upper envs. |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
-
|
other relevant issue that is very similar to this one 👉 https://github.com/orgs/community/discussions/10809 |
Beta Was this translation helpful? Give feedback.
-
|
Let's link the two together: #10809 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Snailedlt, Great point! Setting a default merge strategy for organizations or repositories would significantly improve workflow and minimize errors. Here are a few key suggestions: Repository Settings: Allow admins to set a default merge strategy. Highlighting the default in the merge dropdown (perhaps with color or an emoji) would provide clear guidance to users. These changes could streamline merges and enhance the GitHub experience! |
Beta Was this translation helpful? Give feedback.
-
|
Two years without answer... +1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 I think it would be pretty simple to implement since UI already has |
Beta Was this translation helpful? Give feedback.
-
|
Please papa microsoft, before Lina Khan busts your monopoly |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! 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! |
Beta Was this translation helpful? Give feedback.
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