How it works
01 /
Authorize the person and command
The deployment must enable merge commands, the managed ruleset must reconcile successfully, and the commenter must have write, maintain or admin permission. A command edited or deleted before consumption is withdrawn. A plain issue or a mention inside an ordinary sentence is not a merge request.
02 /
Honor the selected merge method
The default is a squash merge. Apply merge: no-squash to request a merge commit, useful when branch history needs to survive. The App checks both repository settings and effective ruleset restrictions. A refused merge method is reported rather than silently replaced with another method.
03 /
Let GitHub enforce eligibility
Pending requirements or an outdated base enable auto-merge using the same method. Draft, closed or conflicting PRs receive an explanation. The App has no bypass actor in its managed ruleset, and command reservations prevent the same comment from initiating duplicate merge attempts.
A concrete example
Workflow example
/merge
# Optional PR label for a merge commit:
merge: no-squashKnow the boundary
Current limits
This is an explicit merge request, not a tool that decides a change is safe. The GitHub App needs the required write permissions, and the feature must be enabled by the operator. Conflicts and refused methods require a new decision by the author or maintainer.
Common questions
Can /merge bypass a failing check?
No. GitHub enforces the ruleset against the App’s installation token.
What happens if merge commits are disabled?
A no-squash request reports that blocker and stops. It does not fall back to a squash.
Runnerless / early access
Want this in
your workflow?
Get early access ↗Register interest and tell us what slows your CI down. The optional follow-up questions come after your email is saved.