What are signed commits and why would a team require them?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
Signed commits are cryptographically verified with GPG or SSH, proving a trusted author made them. A team requires them so every merged commit is attributable and tamper-evident — GitHub shows a Verified badge and can block unsigned commits via branch protection.
Detailed explanation
By default a commit's author field is free text — anyone can claim to be Alice <alice@example.com>. Signing attaches a cryptographic signature: git commit -S signs with a GPG key (or SSH key via git commit -S with gpg.format = ssh). Git stores the signature in the commit object; anyone with the public key can verify it with git verify-commit. GitHub checks signatures and shows Verified/Unverified badges on commits and tags. Why enforce it: it ties every change to a real identity, deterring impersonation and making the audit trail trustworthy — important in regulated or security-sensitive projects. Enforcement options: branch protection rules requiring signed commits (GitHub Enterprise), CI checks that reject unsigned commits, or pre-receive hooks. Practical setup: generate a GPG key (gpg --full-generate-key), add it to your GitHub account, tell Git your signing key (git config user.signingkey), and enable commit signing globally (git config commit.gpgsign true) or per-repo. SSH signing is simpler to onboard (reuses existing SSH keys) and is now a first-class alternative. The trade-off: key management overhead and a harder onboarding for new contributors.
Example
# Configure GPG signing:
gpg --full-generate-key
gpg --list-secret-keys --keyid-format=long
git config --global user.signingkey <KEYID>
git config --global commit.gpgsign true
# Sign a commit:
git commit -S -m 'feat: add export'
# Verify locally:
git verify-commit HEAD
# SSH signing (simpler onboarding):
git config gpg.format ssh
git config user.signingkey ~/.ssh/id_ed25519.pubInterview tip
Lead with the impersonation problem (author field is free text), then explain GPG/SSH signing and how GitHub surfaces it. Mentioning branch protection enforcement shows you have seen it required, not just read about it.
Common mistakes
- Thinking the author field is verified — it is free text without signing.
- Signing commits but never configuring verification on the server side.
- Overlooking SSH signing as a simpler alternative to GPG.