Git怎么设置GPG签名提交_Git commit签名验证配置教程【进阶】

默认启用 Git 提交 GPG 签名需配置 commit.gpgsign=true 并设置 user.signingkey 为有效密钥 ID，同时确保 GPG 环境就绪；GitHub/GitLab 验证依赖正确上传对应公钥

怎么让 git commit 自动带 GPG 签名

想让你的每一次提交都自动带上 GPG 签名，其实并不复杂，但有几个关键步骤必须走对。首先得明确一点：Git 默认是不会帮你签名的，你得手动开启这个功能。核心就两件事：把配置项 commit.gpgsign 设为 true，并且确保你本地有可用的 GPG 密钥，同时系统能找到 gpg 命令。

• 最直接的方法，运行 git config --global commit.gpgsign true，这样所有仓库的提交都会尝试签名。
• 如果只想对特定仓库生效，去掉 --global 参数，在那个仓库的根目录下执行即可。
• 配置完后，可以用 git config --get commit.gpgsign 确认一下，返回值应该是 true。
• 如果提交时遇到 gpg failed to sign the data 这类错误，别慌。这通常不是 Git 的问题，而是 GPG 环境没准备好——可能是袋里（agent）没启动、密钥过期了，或者私钥根本没导入到当前的 GPG 钥匙环里。

为什么 git commit -S 有时报错 no default secret key

这个报错信息很明确：Git 找不到默认用来签名的私钥。问题不在于有没有安装 GPG，而在于没有明确指定或者正确选中哪一把钥匙。

• 第一步，先用 gpg --list-secret-keys 命令看看你有哪些密钥。找到那串长长的十六进制 ID（比如 ABC1234567890DEF）。
• 第二步，把这个密钥 ID 明确告诉 Git：git config --global user.signingkey ABC1234567890DEF。
• 这里有个常见的坑：密钥 ID 是 sec 行末尾的那一串，不是邮箱地址。如果你使用了子密钥，那必须使用子密钥的 ID（对应 ssb 行末尾的那串）。
• 另外，在一些 Linux 发行版（例如 Ubuntu 22.04 及以上版本）上，系统默认使用 gpg2，但 Git 可能还在调用老版本的 gpg。这时可以加一条配置来对齐：git config --global gpg.program gpg2。

GitHub / GitLab 怎么验证签名并显示 “Verified”

代码平台显示那个绿色的 “Verified” 标签，过程其实并不神秘。平台做的只是校验提交附带的签名本身是否有效，它并不会去联网查询你的密钥在公共领域是否“可信”。所以，关键在于你上传到平台的那份公钥，必须和本地用来签名的私钥严格匹配，并且这把密钥没有被吊销。

• 导出公钥：运行 gpg --armor --export ABC1234567890DEF，复制输出的全部内容（以 -----BEGIN PGP PUBLIC KEY BLOCK----- 开头的那一大段）。
• 上传公钥：在 GitHub 上，路径是 Settings → SSH and GPG keys → New GPG key；在 GitLab 上，则是 Preferences → GPG Keys → Add key。
• 提交后，如果没立刻看到 “Verified”，不妨等上一两分钟再刷新页面，避免缓存导致状态显示延迟。
• 如果推送后很久还是不显示，最好先在本地验证一下：用 git log --show-signature -1 检查最近一次提交的签名状态。如果本地就失败了，通常会看到 error: no signature found 的提示。

CI 环境里签名失败怎么办

在持续集成环境里给提交签名，十有八九会碰壁。这其实不是故障，而是设计如此：CI 环境通常是临时的、非交互式的，既没有 GPG 袋里在运行，也不会存放你的私钥——从安全角度讲，私钥本来就不该进入自动化构建流程。

• 对于绝大多数 CI 场景，一个核心建议是：**不要试图给自动化生成的提交加 GPG 签名**。签名这个动作，应该由开发者在本地完成。CI 流水线的任务，更多的是去验证签名（使用 git verify-commit）。
• 如果确有特殊需求非要在 CI 里签名不可（比如某些自动发布脚本），那就需要将解密后的私钥注入到 CI 环境的 GPG 钥匙环中（通过 gpg --import），并且通常需要禁用密码短语。但必须警惕，这有很高的安全风险，务必严格控制权限。
• 一个更安全的折中方案是，在 CI 脚本里使用 git commit --no-gpg-sign 来覆盖全局的自动签名设置，或者临时取消 commit.gpgsign 这个配置。
• 还有一个细节：GitHub Actions 的 actions/checkout@v4 默认只拉取最近一次提交（fetch depth=1），这会导致 git verify-commit 在验证历史提交的签名链时失败。解决方法是在工作流配置中加上 fetch-depth: 0。

说到底，GPG 签名要真正发挥作用，离不开一个稳固的“三角支撑”：开发者自己妥善保管私钥、在代码平台准确录入对应的公钥、Git 配置精准指向正确的密钥 ID。三者缺一不可。实践中，最容易栽跟头的地方往往是密钥 ID 写错了（比如误用了主密钥ID去配置子密钥），或者以为安装了 GPG 工具就万事大吉，结果根本没生成或导出过有效的密钥对。