Signing commits and tags with an SSH key or GPG

Goal

Attach a verifiable signature to commits and release tags so that a reviewer or build can check that a change came from a holder of a known key, not merely from someone who typed a name into user.email.

Prerequisites

Git with gpg.format support (the git-config documentation lists the values openpgp (default), x509 and ssh). For SSH signing: an SSH key pair and ssh-keygen from OpenSSH, which does the signing. For GPG: a key pair with a key ID. A place to publish public keys, such as the hosting platform's account settings.

Steps

1. Choose the format. SSH reuses the key developers already have and needs no key server; GPG carries a web-of-trust model and expiry. Set git config --global gpg.format ssh (or leave the default for GPG).
2. Name the key: git config --global user.signingKey ~/.ssh/id_ed25519.pub for SSH (GitHub's guide shows the same commands), or the GPG key ID.
3. Turn signing on by default: git config --global commit.gpgSign true and git config --global tag.gpgSign true. The documentation notes that rebases then sign many commits, so use an agent to avoid repeated passphrase prompts.
4. Verify locally. With SSH, create an allowed-signers file with lines of principal ssh-ed25519 AAAA... and point gpg.ssh.allowedSignersFile at it; the documentation states that SSH has no trust levels: a key listed in this file gives trust level "fully", otherwise git verify-commit and git verify-tag fail, so this file is the whole trust decision. Then run git verify-commit HEAD and git verify-tag v1.2.0, or git log --show-signature.
5. Upload the public key to the hosting platform as a signing key so its interface marks commits verified.
6. Sign release tags with git tag -s v1.2.0 -m "..."; only annotated tag objects can carry a signature.
7. For key rotation, keep the old public key in the allowed-signers file with valid-after and valid-before options (OpenSSH 8.8 or newer, per the documentation); Git then accepts signatures made while the key was valid. Revoked keys go into gpg.ssh.revocationFile, a KRL or plain key list whose entries are always reported invalid.

Expected result

git verify-commit reports a good signature for signed commits, the platform shows them as verified, and an unsigned or wrongly signed commit is visible as such in review and can be rejected by branch rules.

Limits and test basis

A signature proves possession of a key at signing time, not that the change is correct or that the key holder is who the name says. Squash or rebase merges performed by the hosting platform create new commits that carry either no signature or the platform's own. Behaviour follows the cited documentation; no measurement of adoption or effort is claimed.