Currently pull request merge options are set on a repository level. It would be fantastic if these could be set or overridden based on:
A) Where the pull request head branch lives, i.e. within the organization repository vs. a fork.
B) Branch name patterns, the same way branch protection rules works.
The reason behind this feature request is that merging between shared branches (i.e. within the org repo) should allow for blocking rebases and squashes, since these change the commit history & hashes. The Golden Rule of Rebasing calls these “public branches”, but “public” can be a misnomer because orgs can have private repos, so “shared branches” describes them better.
Since fork feature branches are not typically shared/“public”, it would be great to force either a rebase or squash. This benefit here is that squashing can save manual developer time in cleaning up commits (ex. manually rebasing), and rebasing allows keeping multiple commits intact without adding an empty merge commit.
These are some of the drivers behind using PRs to merge shared branches (ex. develop into master):
- PRs enforce required status checks (via branch protection rules) pass, such as automated testing via CI
- Manually merging and pushing to protected branches from local requires admin rights, and for admins to be excluded from branch protection rules (while admins can change any branch protection rules, sometimes it’s nice to leave “Include administrators” on)
- PRs reduce the manual work of merging and pushing updates from local, and eliminate the risk of human error when doing this
- PRs maximize transparency within the repo (and or) by having PR history available for changes to shared branches, especially master
- When using branch protection, PRs allow non-admins to advance code through the branch flow/code life cycle. Delegating saves admins’ time and provides a standard/consistent process for merging shared branches
- An organization repository uses a gitflow branch model and a fork & pull request workflow
- develop, master, hotfix, and release branches only allow squashing or rebasing on PRs where the base branch is from a fork
- master only allows merge commits for PRs that merge in a hotfix or release branch that lives within the org’s repo, and for leaner branching models this would be when merging develop into master
- develop only allows merge commits for PRs that merge in: the latest master, any hotfix branch, or an updated release branch (ex. release candidate has a bug fix merged, release candidate is merged back into dev instead of creating a separate fork feature branch to update develop)