GitHub · Pull requests · Rulesets · Checked October 26, 2026

GitHub: a merge or push is blocked by commit metadata rules

Organizations on a GitHub Enterprise plan can add rules that control how commit metadata must be formatted: the commit message, the author's email and the committer's email, and the names of new branches and tags. If a contributor tries to update a branch or tag with a commit that does not meet them, GitHub shows an error saying what was wrong, both in the command line when the contributor pushes and on GitHub when they make a commit or merge a pull request (GitHub's available rules for rulesets, checked October 26, 2026).

{ "type": "commit_message_pattern",
  "parameters": { "name": "Issue key", "operator": "starts_with",
                  "pattern": "SHOP-", "negate": false } }

The rules

Five kinds: in the REST API they are commit_message_pattern, commit_author_email_pattern, committer_email_pattern, branch_name_pattern and tag_name_pattern. Each has an operator (starts_with, ends_with, contains or regex), a pattern, an optional name, and negate for "must not" (GitHub's REST API endpoints for rules).
Literal patterns: for most requirements, such as "Must start with a matching pattern", the pattern is taken literally and wildcards are not supported: * is just the character *.
Regular expressions: with "Must match a given regex pattern" or "Must not match a given regex pattern", rulesets use RE2 syntax. By default an expression does not consider multiple lines: ^ABC matches a multiline commit message whose first line starts with ABC, and an expression that starts with (?m) matches across lines. The negative lookahead ?! is not supported. For an end-of-line anchor, GitHub advises \n?$ rather than $ alone, because a trailing newline may be present in Git push and command line flows (GitHub's regular expressions for commit metadata).
Sign-off: when commit sign-off is required, GitHub adds a line like Signed-off-by: NAME <EMAIL> to the commit message, which may interfere with a pattern.

How they apply

They block the branch update, not the push: a push that includes a commit that does not meet the rules is not rejected, but the branch or tag it targets is not updated. The commits still enter the repository and can be opened, but they are not connected to the history of a branch or tag. Other branches or tags in the same push whose commits meet their rules are updated.
New commits only: rules added to an existing branch or tag apply to the new commits pushed from then on, not to its existing history.
Squash merges: GitHub's article says that with a squash merge the individual commits of the pull request are ignored and only the metadata of the single resulting commit is checked, which the pull request page checks before it allows the merge. A note in the same section says that if you squash merge a branch, all commits on that branch must meet the base branch's metadata requirements.
Merges made on GitHub: for a rule on committer emails, the pattern must also include noreply@github.com for web-based merges and other commits created on GitHub.

What to do

Read the pattern in the error: when commits are rejected, the message tells you the pattern the metadata needs to match (GitHub's troubleshooting rules).
Rewrite the commits: commits are immutable in Git, so a commit's metadata cannot be edited once it is made. You may need to rebase to squash the commits or rewrite each commit individually, then push the new commits.
For a squash merge: GitHub checks the resulting commit, so write the commit title the merge gives it so that the message meets the rule; with a committer email rule, check that the rule allows noreply@github.com.
Find the rule: anyone with read access can view a repository's active rulesets. In the repository's settings, Rules then Insights shows the actions checked against rulesets and, for a failed one, which rules failed (GitHub's managing rulesets for a repository).
For administrators: GitHub suggests putting metadata rules on a limited set of branches, such as main only with pull requests required into it, rather than on every topic branch, and trying them first with the "Evaluate" enforcement status, which shows in Insights what would have passed or failed.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff, and merges it with the methods the target branch allows. Its merge dialog shows the target branch's commit metadata rules under the commit title, and stops a title the commit message cannot meet a rule with (a required start, or a text it must not contain); when a committer email rule does not allow noreply@github.com, it says so. GitHub still checks the rules on the merge's commit. The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.