How do you configure Git to sign every commit and tag automatically?

## What signing attaches to Git can sign two kinds of object. A **signed commit** carries the signature in a header of the commit object itself, alongside the tree, parents, author, committer and message. A **signed tag** is an annotated tag object whose payload is signed the same way. Both are ordinary Git objects, so the signature is content-addressed along with everything else: change any byte and you have a different object and an invalid signature. Lightweight tags cannot be signed at all — they are just a ref pointing at a commit, with no object of their own to hold a signature. That is why release processes that care about provenance use annotated, signed tags. ## The configuration **`user.signingKey`** identifies which key to use. With the default OpenPGP backend it is a key id or fingerprint. With SSH signing it is the path to a public key file (for example `~/.ssh/id_ed25519.pub`), or a literal key given in the `key::ssh-ed25519 AAAA...` form. **`gpg.format`** selects the backend: `openpgp` (the default), `ssh`, or `x509`. SSH signing is the low-friction option for teams that already have SSH keys, and it needs a version of `ssh-keygen` that supports the `-Y sign` and `-Y verify` subcommands. **`commit.gpgSign`** set to true signs every commit `git commit` creates, so you stop typing `-S`. **`tag.gpgSign`** set to true does the same for annotated tags. Note the asymmetry in the porcelain: `git tag -a` creates an annotated tag *without* a signature, `git tag -s` creates a signed one, and `git tag -u <keyid>` signs with a specific key. **`gpg.program`** points at the signing binary if the default is wrong for your machine. **`gpg.ssh.allowedSignersFile`** is not needed to *create* SSH signatures but is required to *verify* them; without it, verification reports that it has no way to check the key. ## Doing it per command Everything above has a per-invocation equivalent: `git commit -S`, `git commit -S<keyid>`, `git tag -s`, `git tag -u <keyid>`. Going the other way, `--no-gpg-sign` disables signing for one command even when the config says to sign — useful for a throwaway commit, or for a scripted operation running where no key is available. The same options exist on the commands that create commits indirectly: `git merge -S`, `git cherry-pick -S`, `git rebase -S`. That matters because a rebase can create many commits at once, which with signing enabled means many signing operations — the standard advice is to run an agent that caches the passphrase, or the operation becomes an interrogation. ## Where to put the settings Signing identity is usually a per-machine, per-identity concern rather than a per-repository one, so the settings normally live in the user's global config. Work and personal identities that use different keys are the classic reason people split their config per directory. What you cannot do is ship signing configuration inside the repository for others to inherit — `.git/config` is not cloned, and a key path is meaningless on someone else's machine. ## Verifying that it took effect After configuring, make a commit and check it: `git log --show-signature -1` prints the verification result, and `git cat-file -p HEAD` shows the raw commit object with its signature header, which is the most convincing demonstration that the signature is part of the object rather than metadata bolted on beside it. `git log --pretty="%h %G? %GS"` gives a compact one-line-per-commit view of signature status and signer across a range. ## Common failure modes A signing key that has expired, a passphrase prompt that cannot reach a terminal (the classic failure inside an editor or a script), a `user.email` that does not match any identity on the key, or `gpg.format = ssh` with `user.signingKey` pointing at a private key path when the public key is expected. Each produces a commit that fails to be created rather than one that is silently unsigned, which is the behaviour you want. ## Interview framing Name the three settings precisely, distinguish creating signatures from verifying them (the allowed-signers file is only needed for the second), mention that lightweight tags cannot be signed, and note the agent/passphrase practicality that anyone who has actually turned this on has hit.