Every time someone runs a commit in Git, a small text record is created: who made the change, when, what the message says, and a pointer to the exact state of every file at that moment. That record has an identity field — a name and an email address — but Git never checks whether the person typing the command actually owns that email address. Anyone with commit access, or anyone who can push to a fork, can set their Git configuration to say author: Linus Torvalds and Git will happily accept it. The commit history, on its own, is a claim, not a proof.

A digital signature closes that gap. It is a small block of cryptographic data, generated using a private key that never leaves the signer’s machine, and attached to the commit (or to a Git “tag”). Anyone holding the matching public key can mathematically verify that the signature could only have been produced by someone in possession of the private key, and that the commit’s content has not been altered by even a single byte since it was signed. Change one character in the commit message after signing, and the signature no longer matches — verification fails immediately.

GitHub supports three signing mechanisms today: GPG (GNU Privacy Guard, the traditional PGP-style key pair), SSH signatures (reusing the same SSH key pair many developers already use to push code), and S/MIME (X.509 certificate-based signing, more common in enterprises with existing certificate infrastructure). All three plug into the same GitHub feature: once a commit or tag carries a valid signature from a key GitHub has on file for that user, GitHub marks it Verified in the UI, with a small green badge next to the commit.

What “Required Signatures” Actually Requires

“Require signed commits,” the specific branch protection rule this article focuses on, is a switch a repository administrator can flip on a protected branch. Once enabled, GitHub’s server-side push logic rejects any push that contains a commit without a valid, verifiable signature attached. It does not matter how good the code is, how trusted the contributor normally is, or whether the pull request has ten approving reviews — an unsigned commit simply cannot land on that branch. This is enforced at the Git protocol level during the push, not as a cosmetic warning after the fact.

To understand why a whole cryptographic system was built around something as small as a commit, it helps to look at what goes wrong without it. Git’s design makes the author and committer fields on every commit fully user-editable plain text, set locally with a simple configuration command. Nothing stops a person from configuring their local Git identity to impersonate a well-known maintainer, a teammate, or even a bot account, and then pushing a commit that appears, in the history and in most tools, to have come from that person.

This is not a theoretical concern. Security researchers have repeatedly demonstrated commit spoofing as a proof of concept, and it has shown up as a real attack vector: an attacker with access to a shared build system, or a compromised CI credential, can push a malicious commit that is falsely attributed to a trusted senior engineer, making the change look far more credible during a quick review and slowing down detection. In a large open-source project accepting contributions from thousands of pseudonymous accounts, there is no inherent guarantee that the “author” name on a patch corresponds to a real, consistent identity at all.

Required signatures exist to remove this blind spot for the specific branches that matter most — typically main, release branches, and anything that feeds a production deployment pipeline. It converts “the commit says it’s from Priya” into “cryptography proves this could only have come from a private key Priya controls, and it has not been altered since.”

The Supply-Chain Angle

This problem became sharply more urgent industry-wide following a string of software supply-chain incidents where attackers inserted malicious code deep inside dependency chains, sometimes by compromising a maintainer’s account or build infrastructure rather than breaking cryptography directly. Frameworks like SLSA (Supply-chain Levels for Software Artifacts) and the broader push toward software provenance explicitly call out commit signing as a foundational control: if you cannot cryptographically prove who authored a change, you cannot build a trustworthy chain of custody for the software built from it.

1. The Key Pair

Every signer generates (or already has) an asymmetric key pair: a private key kept secret on their own machine, and a public key that is safe to share widely. For GPG or S/MIME this is a dedicated signing key; for SSH signing, many developers reuse the exact same key pair they already use to authenticate pushes over SSH, which is one reason SSH signing has become popular — there is often nothing new to generate.

2. The Local Git Client

When signing is turned on locally, the Git client (or the code editor wrapping it) automatically runs the signing operation as part of creating each commit, attaching the resulting signature block to the commit object before it is ever transmitted anywhere.

3. GitHub’s Public Key Store

Each GitHub account has a settings page where the user uploads their public key (GPG, SSH signing key, or an S/MIME certificate). GitHub stores this and associates it with that account’s identity. This is the “known fingerprint on file” that later verification checks against.

4. The Signature Verifier

On every push, GitHub’s backend runs each commit’s signature through standard cryptographic verification, checking that the signature mathematically matches the commit content and that it was produced by a private key whose public counterpart is on file and trusted for that identity.

5. The Branch Protection Rule Engine

This is the enforcement layer. Branch protection rules are evaluated per push, per branch. “Require signed commits” is one of many possible conditions (alongside required reviews, required status checks, and required linear history) that all must pass before a push is accepted onto that specific branch.

At the heart of every signature scheme GitHub supports is the same mathematical idea: asymmetric cryptography, where two keys are generated together as a pair, and an operation done with one key can only be undone or verified with the other. For signing specifically, the private key produces a signature over the commit’s content, and the public key is used to check that signature — but the public key alone cannot forge a new valid signature.

When a commit is signed, the signing tool does not encrypt the whole commit. Instead, it computes a cryptographic hash — a fixed-length fingerprint of the commit’s exact content (tree pointer, parent commit, author, committer, timestamp, and message) — and then signs that hash with the private key. Because a hash function is designed so that even a one-character change produces a completely different fingerprint, the signature effectively locks in every detail of the commit at once.

Why Changing History Breaks Signatures

Because the signature covers the commit’s parent pointer as well, any attempt to rewrite history — even something as small as amending an old commit message deep in the chain — produces a completely new hash for that commit and every commit built on top of it, invalidating every signature downstream unless each one is re-signed. This is precisely why signed commit history is considered strong evidence against silent, undetected tampering: an attacker cannot quietly edit an old commit without either breaking every signature after it or needing access to every relevant private key to re-sign the whole chain.

Tracing a single commit from a developer’s keyboard to a protected branch makes the whole system easier to hold in your head as one continuous flow rather than a list of disconnected facts.

Pull Requests Add a Layer

Most teams do not push directly to a protected branch; they open a pull request from a feature branch, which is merged later. Required signatures still applies at the moment of merge (or at the moment individual commits land, depending on the merge strategy chosen): a “squash and merge” typically produces one new merge commit that itself must be signed by whoever or whatever performs the merge, while “rebase and merge” or a fast-forward merge preserves each original commit’s own individual signature. This distinction surprises many teams the first time they turn the setting on, because it changes which actor’s key needs to be trusted at merge time.

The Central Trade-off

Required signatures trades short-term contributor convenience for long-term, provable integrity. For a small internal tool with two trusted maintainers, this trade-off is rarely worth the operational overhead. For a widely-forked open source project, a regulated financial system, or any codebase feeding a software supply chain that other organizations depend on, the trade-off usually favors turning it on, because the cost of an undetected forged commit vastly outweighs the friction of key management.

Required signatures is, at its root, a security control, so it is worth examining what it defends against precisely — and, just as importantly, what it does not.

Layering With Other Controls

Because of these gaps, mature security programs never treat required signatures as a complete solution on its own. It is typically layered with required pull request reviews (a second human must approve the change), required status checks (automated tests and security scans must pass), required linear history (no confusing merge topology to hide changes in), and, increasingly, hardware-backed signing keys (stored on a physical security key rather than a laptop disk) for the highest-privilege contributors such as release managers.

Turning a control on is only half the job; a security-conscious team also needs visibility into how it is behaving day to day.

Organizations at scale often pipe this data into their existing security dashboards, alongside secret-scanning and dependency-vulnerability metrics, treating “percentage of commits verified on protected branches” as a tracked health indicator, not a one-time setup task.

Common Mistakes