GitHub · Pull requests · Signed commits · Checked October 26, 2026

GitHub: the merge is blocked by unsigned commits

A branch protection rule or a ruleset can require signed commits. Then contributors and bots can only push commits that have been signed and verified to the branch (GitHub's about protected branches and available rules for rulesets). A pull request into that branch is held to it too: to tell whether it can be merged, GitHub creates a test merge commit whose parents are the latest commit on the base branch and the pull request's head commit, and checks the commits that test merge introduces, including those from the head branch. So unsigned commits on the head branch can block a squash merge, even though GitHub would sign the final squash commit, and this can apply to the pull request's author as well. GitHub calls such a pull request blocked; GraphQL's mergeStateStatus is then BLOCKED, "The merge is blocked" (checked October 26, 2026).

GET  /repos/OWNER/REPO/pulls/N/commits               → commit.verification.verified, reason (up to 250 commits)
GET  /repos/OWNER/REPO/rules/branches/BRANCH        → rule "required_signatures"
GET  /repos/OWNER/REPO/branches/BRANCH/protection   → required_signatures.enabled

Which commits count

Every commit the merge brings in: not only the head commit. An older unsigned commit on the head branch, introduced by the test merge, blocks as much as the latest one.
Signed and verified: GitHub marks a commit "Verified" when it is signed (GPG, SSH or S/MIME) and the signature was successfully verified; a commit that is signed but whose signature could not be verified is "Unverified" (GitHub's about commit signature verification). Required commit signing blocks all commits that are not signed and verified. If you have enabled vigilant mode, commits GitHub identifies as "Partially verified" are permitted.
Made on GitHub: GitHub signs commits you make in the web interface with GPG, and they are verified. A GitHub App's or bot's commits are verified when the request is authenticated as the app and carries no custom author, committer or signature information. With Rebase and merge, GitHub creates modified commits from the head branch's commits and cannot sign them on your behalf, so they are added to the base branch without commit signature verification; the documented workaround is to rebase and merge locally and push the result.
Once verified, it stays so: when a signed commit is pushed and verified, GitHub stores a verification record with it (the REST API's verified_at). It persists even if the key is later rotated, revoked or expired; GitHub does not re-verify such commits.

Why a commit is not verified

The reason: each commit in the REST API carries a verification object with verified and reason: unsigned (no signature), unknown_key (the key is not registered with any user's account), no_user, unverified_email or bad_email (the committer email address belongs to no user, is not verified on the account, or is not among the key's identities), expired_key, not_signing_key, malformed_signature, invalid, and gpgverify_error or gpgverify_unavailable (the verification service) (GitHub's REST API endpoints for commits).
The commits of a pull request: "List commits on a pull request" returns up to 250 commits, each with commit.verification; for a longer pull request, the List commits endpoint gives the complete list.
Where the rule is: in a branch protection rule, "Require signed commits" (required_signatures.enabled; "Get commit signature protection" answers it to admin or owner permissions); in a ruleset, the required_signatures rule, which "Get rules for a branch" returns among the active rules for the branch.

What to do

Rewrite and sign: rewrite the unsigned commits on the head branch with a verified signature and force push them; GitHub's own advice for an unsigned commit pushed to a branch that requires signatures is to rebase it to include a verified signature, then force push. Force push carefully, so that work others based on the branch is not overwritten.
Fix the cause first: for unknown_key, add the signing key to your GitHub account; for an email reason, commit with a verified address the key covers. Then sign the commits again.
Squash locally: you can squash and merge locally, but you must sign the resulting commit before pushing it to the branch; if another protection requires changes through a pull request, you may also need bypass permissions to push it.
Ask someone who can bypass: by default the restrictions of a branch protection rule do not apply to people with admin permissions or roles with the "bypass branch protections" permission, unless "Do not allow bypassing the above settings" is on; a ruleset names who may bypass it. Someone with permission to bypass the applicable protections can merge the pull request.
Check the other rules: signatures are one requirement among others: approving reviews (see a code owner's review), resolved conversations (see the merge waits for conversations), required checks (see a required check stuck at "Expected"), a branch that must be up to date.

In IntelliJ IDEA: the flag is fetched, the signatures are not

How the GitHub support built into IntelliJ IDEA deals with required signed commits, in its source (checked November 1, 2026; IntelliJ IDEA: refUpdateRule.graphql, GHPRMergeabilityStateBuilder.kt, GraphQL files, GithubApiRequests.kt):

The rule: for the base branch it asks GitHub for requiresSignatures, but the code that works out whether the pull request can be merged takes only the required checks, whether your account can push and the required approvals from that rule.
The commits: none of its 78 GraphQL files asks for a commit's signature, and its list of REST requests has nothing for signatures, so it does not read whether a commit is signed or verified. What it reads for each commit: a co-author is not credited for a commit.

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. When GitHub calls the pull request blocked, its merge checks say the rules of the target branch are not met yet (required reviews or required checks), and name what they can read: required checks that have not reported, a review still required, unresolved conversations the rules want resolved. When a blocked pull request has commits that GitHub does not report as signed and verified, they are counted and named there, and said to hold the merge back when the target branch's ruleset or protection requires signed commits; when those rules cannot be read, as what may hold it back. 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.