Safeguard
Developer Tools•

Why does a squash merge fail when signed commits are required?

GitHub checks every commit a squash merge would introduce, including unsigned ones on the head branch. Why it blocks and three ways to unblock it.

Safeguard Security Team
3 min read

Because GitHub checks more than the final squash commit. With required signed commits, it builds a test merge and checks every commit the merge introduces, including unsigned commits on the pull request branch. GitHub signs the squash commit itself, but unsigned head commits can still block it.

What GitHub documents

GitHub's protected branch page says a squash merge is evaluated by creating a test merge commit and checking every commit it introduces. That includes unsigned commits on the head branch. The page adds that this can apply to the pull request author's own commits.

So the error message can feel odd. The commit that would land is signed by GitHub, yet the merge is blocked. The rule looks at what is inside it.

Ways to unblock a pull request

  1. Rewrite and sign the unsigned commits, then force push to the pull request branch. Since a rewrite changes the diff history, expect approvals to be dismissed if that setting is on.
  2. Ask someone with bypass permission to merge. Use this sparingly and leave a comment explaining why.
  3. Open a fresh branch, cherry pick with signing enabled, and replace the old pull request.

Partially verified commits are allowed when vigilant mode is on, which the page also notes.

Prevent it for the next contributor

  • Put signing setup in your onboarding guide, with the exact commands for the editor you use.
  • Add a pre-push check that warns when a local commit is unsigned.
  • Decide whether you really need signed commits on every branch. Many teams require them on the default branch and release branches only.
  • Pair the rule with required reviews so that a signature proves who committed, and a reviewer proves the change was read.

A signature shows that a key you registered signed the commit. It does not say the code is safe. Treat it as one control among several.

A note on linear history

If you also require linear history, merge commits are blocked and pull requests must land by squash or rebase. Squash or rebase merging must be enabled in the repository first. That combination keeps history readable but makes the signing check above more visible, so test both together on a sample pull request. Write the result into your contributing guide, including the error text people will see, so the next person can fix it in five minutes instead of opening a ticket.

Where Safeguard fits

Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Does GitHub sign squash commits?

The documentation notes that GitHub signs the final squash commit, but unsigned commits on the head branch can still block the merge.

What is the quick fix?

Rewrite and sign the unsigned commits, or have someone with bypass permission merge.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.