先运行 gpg --version 确认GPG已安装且可用，再执行 git config --global commit.gpgsign true 启用默认签名，并通过 git config --global user.signingkey <KEY_ID> 绑定密钥，最后用 git log --show-signature 验证签名有效性。
怎么确认本地 Git 已启用 GPG 签名支持
Git 本身不自带 GPG，签名能力依赖系统已安装的 gpg 命令。运行 gpg --version 能看到版本号，且返回码为 0，才算基础就绪。Windows 用户若用 Git for Windows，默认捆绑的是 gpg.exe（位于 Git 安装目录的 usr/bin/ 下），但 Git 可能找不到它——需手动设置 gpg.program：
git config --global gpg.program "C:/Program Files/Git/usr/bin/gpg.exe"macOS 上用 Homebrew 安装的 GPG，路径通常是
/usr/local/bin/gpg；M1/M2 芯片设备可能落在 /opt/homebrew/bin/gpg，务必核对。
如何生成并配置用于 Git 提交签名的密钥对
不要复用已有密钥（比如 SSH 或邮箱登录密钥），Git 签名应专用。执行 gpg --full-generate-key，选择 RSA（4096 位），姓名和邮箱必须与 Git 的 user.name / user.email 完全一致——大小写、空格、前后缀都影响验证。生成后用 gpg --list-secret-keys --keyid-format=long 查看密钥 ID（形如 ABCDEF1234567890），再绑定到 Git：
git config --global user.signingkey ABCDEF1234567890注意：密钥 ID 是长格式（16 进制 16 位），不是短 ID（8 位）或指纹（40 位），填错会导致签名失败但无明确提示。
怎样让特性分支（feature branch）每次提交自动签名
仅靠 git commit -S 手动加参数太容易漏，必须设成默认行为。启用全局自动签名：
git config --global commit.gpgsign true这会让所有本地仓库的
git commit 默认签名。但注意：如果某仓库需要临时关闭（比如向不支持签名的 CI 推送），可在该仓库内覆盖：git config commit.gpgsign false更关键的是，
git merge 和 git rebase 不会自动签名合并提交或变基后的提交——它们仍需显式加 -S，否则特性分支上的历史会出现混杂（部分有签名、部分无），破坏完整性验证链。
为什么 push 到远程后别人验不了你的签名
签名本身只附在 commit 对象里，Git 服务器（包括 GitHub、GitLab）默认不校验也不展示，更不会拦截无效签名。要让协作方能验证，必须满足三个条件：① 你把公钥上传到对应平台（GitHub 在 Settings → SSH and GPG keys；GitLab 在 Preferences → GPG Keys）；② 提交的邮箱必须是平台已验证的邮箱；③ 对方 clone 后需导入你的公钥（gpg --import your-public-key.asc）或信任 Web 密钥目录（WKD）。常见错误是：公钥传上去了，但 commit 里用的邮箱拼错一位，或用了未验证的别名邮箱——此时 GitHub 页面会显示 “Unverified” 而非 “Verified”，且 git verify-commit HEAD 会报 gpg: Can't check signature: No public key。
真正麻烦的是团队协同场景：有人忘了开 commit.gpgsign，有人用错密钥，还有人 rebase 后没重签——这些都会导致同一分支里签名状态不一致。验证不能只靠 GitHub 绿标，得在本地用 git log --show-signature 逐条看，尤其关注 merge 和 cherry-pick 提交。
