Signed Commits and Security
Git records an author name and email on every commit, but neither is verified — anyone can set 'git config user.name' and 'user.email' to any value, including someone else's identity, and Git will happily record it. Commit signing closes this gap by attaching a cryptographic signature to a commit (or tag) using a private key the committer controls, which platforms like GitHub can then verify against a public key on file for that account. A verified signature does not just say 'someone claims to be this person' — it proves the commit was created by whoever holds the corresponding private key, which is a meaningfully stronger guarantee, especially for security-sensitive projects, release tags, or any workflow where supply-chain integrity matters.
Cricket analogy: Anyone can scrawl 'M.S. Dhoni' on a scoresheet without proof, but a verified fingerprint scan at the pavilion gate proves the person signing in is genuinely him, a far stronger guarantee than a self-reported name.
GPG signing vs SSH signing
Git originally supported signing via GPG (GNU Privacy Guard) keys, which requires generating a GPG keypair, uploading the public key to your Git hosting account, and configuring Git to sign with it. More recently, Git added support for signing commits with SSH keys — the same keys many developers already use for authentication — which lowers the barrier significantly since no separate GPG toolchain is needed. Both approaches produce a cryptographic signature over the commit's content (message, tree, parent, author, committer); the hosting platform then checks that signature against the public key associated with the account and marks the commit 'Verified' in the UI.
Cricket analogy: A club can authenticate a signed shirt via a notarized certificate requiring a separate process, or by reusing the same biometric ID card players already carry for stadium access; either way the verification desk marks it 'Verified.'
# GPG signing setup
gpg --full-generate-key
gpg --list-secret-keys --keyid-format=long
git config --global user.signingkey 3AA5C34371567BD2
git config --global commit.gpgsign true
git commit -S -m "feat: add rate limiter to auth endpoint"
# SSH signing setup (Git 2.34+)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git commit -S -m "fix: patch CVE-2026-1234 in dependency parser"
# Verify a signature manually
git log --show-signature -1
git verify-commit HEADSigning proves who authored the commit content; it says nothing about whether that content is correct or safe. A malicious actor with a legitimately signed commit can still introduce a vulnerability — signing establishes accountability and non-repudiation, not code quality. Treat it as a complement to code review, not a substitute for it.
History rewriting operations — rebase, amend, filter-repo — strip existing signatures from any commit they rewrite, because the signature covers the commit's exact content and parentage, both of which change. Re-signing is required after such operations, and 'git commit --amend --no-edit -S' is a common way to re-sign the most recent commit.
Enforcing signatures and supply-chain security
Signing is only a meaningful guarantee if it is actually verified and enforced somewhere. GitHub branch protection can require that every commit merged into a protected branch be signed and verified, rejecting merges that include unsigned or unverifiable commits. This matters for supply-chain security frameworks like SLSA, which push toward provenance guarantees for every artifact: knowing exactly which verified identity produced each commit that ended up in a release is a foundational piece of being able to answer 'can we trust this build.' Signed tags extend the same guarantee to releases specifically — 'git tag -s v2.4.0' produces a tag whose authenticity can be verified independent of who currently has push access to the repository.
Cricket analogy: A domestic board can mandate every squad selection sheet be countersigned by a verified manager, rejecting unsigned sheets, so the season's final standings trace back to legitimate selections, just as a signed release tag proves authenticity independent of who holds admin access.
- Git's author name and email fields are unauthenticated by default — anyone can set them to anything.
- Commit signing (GPG or SSH) cryptographically proves a commit came from the holder of a specific private key.
- GitHub marks signed commits 'Verified' after checking the signature against a public key on the account.
- Rebasing, amending, or otherwise rewriting a commit strips its existing signature and requires re-signing.
- Branch protection can require verified signatures on every commit merged into a protected branch.
- Signing proves authorship, not correctness — it complements code review rather than replacing it.
Practice what you learned
1. By default, how does Git verify the author name and email recorded on a commit?
2. What does a 'Verified' badge on a signed commit actually guarantee?
3. Why does rebasing a signed commit invalidate its signature?
4. What Git 2.34+ feature lowered the barrier to commit signing for many developers?
5. In the context of supply-chain security, what is the main value of requiring signed and verified commits on a protected branch?
Was this page helpful?
You May Also Like
Branch Protection and CI Checks
Explore how branch protection rules and required CI status checks stop broken or unreviewed code from reaching important branches like main.
Git Tags and Releases
Understand how git tags mark specific commits as meaningful milestones like versions, and how lightweight vs annotated tags support release workflows and reproducible deployments.
Amending and Rewriting Commits
Amending lets you fix the most recent commit's message or contents without creating a new commit, while broader history rewriting tools reshape older commits before sharing them.
Interactive Rebase
Interactive rebase lets you reorder, squash, edit, or drop commits before they land, turning a messy work-in-progress history into a clean, reviewable narrative.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics