Repository Settings currently expose a single "Merge strategies" configuration that applies globally to all pull requests in a repo. This is insufficient for teams using a multi-stage branching model (e.g., feature → dev → stage → master), where different target branches warrant different merge strategies.
Requested feature: Allow "Allowed merge strategies" and "Default strategy" to be configured per destination branch (or branch pattern), similar to how Branch Permissions already scope rules to a branch pattern.
Use case: Feature branches merging into dev produce excessive small, low-value commits (WIP, fixups, review comments) that pollute history — we want these squash-only. However, promotions from dev → stage → master need to preserve merge commits, since our release/audit process relies on the merge commit boundary to identify what shipped in each deploy.
Current limitation: Because merge strategy is repo-global, we cannot enforce squash-only for feature branches without also breaking the merge-commit requirement for release promotions. Today the only options are (a) allow all strategies and hope the person merging picks correctly, or (b) build a workaround via CI pipelines to bypass the PR merge button for promotions — both of which shift a repo-configuration problem onto manual process or engineering effort.
Ask: Extend Branch Permissions (or the Merge Strategies settings page) to accept a per-branch-pattern override of allowed/default merge strategy, so this can be enforced structurally rather than by convention.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.