在Git 2.2.0的发行说明中，它描述了git push，--signed的新选项：
"git push" learned "--signed" push, that allows a push (i.e.
request to update the refs on the other side to point at a new
history, together with the transmission of necessary objects) to be
signed, so that it can be verified and audited, using the GPG
signature of the person who pushed, that the tips of branches at a
public repository really point the commits the pusher wanted to,
without having to "trust" the server.
因此，这听起来像是在推送过程中发送到服务器的数据已签名，以便服务器可以验证并记录谁进行推送。在man pages中，您可以确认：
--signed
GPG-sign the push request to update refs on the receiving side,
to allow it to be checked by the hooks and/or be logged. See
git-receive-pack[1] for the details on the receiving end.
您可以查看pre-receive和post-recieve下的man pages for git-receive-pack内容，了解如何验证签名推送。
似乎所有这些都有助于服务器验证谁正在进行推送确实是他们所说的人。
git push --signed如何帮助您（推动者）不必“信任”服务器？到目前为止，我所看到的一切似乎都表明它有助于服务器信任您。更重要的是，为什么签名提交和签名标签不足以推送到不受信任的服务器？为什么我们甚至需要签名推送？
答案 0 :(得分：9)
以下是引入签名推送的commit message的摘录：
虽然签名标签和提交声明对象因此签名 来自你，谁签署这些对象，没有一个好方法 断言你想要一个特定的对象在一个尖端 特别的分支。我的签名v2.0.1标签只表示我想打电话 版本v2.0.1，并不意味着我想把它推到我的 ＆＃39;主＆＃39;分支---很可能我只想要它在'maint＆＃39;中，所以 仅对象上的签名是不够的。
唯一可以保证你能够保证＆＃39; maint＆＃39;指出我想要的 那里的地方来自你对托管网站和我的信任 使用它进行身份验证，以后无法轻松审核。
因此，即使提交已签名，您也无法确定作者是否希望将提交推送到分支master或分支super-experimental-feature。签名推送允许服务器记录每个推送事件及其签名。然后可以验证此日志以查看每个提交确实打算在特定分支上。
答案 1 :(得分：1)
尽管已签名的推送确实允许服务器保留每个推送事件及其签名的记录，但它可能无法在Git 2.19（2018年第三季度）之前记录正确的用户：
“ git send-pack --signed”（因此通过http传输的“ git push --signed”）未从配置机制中读取用户身份来确定谁将推送证书签署为已更正。
请参见commit d067d98的Masaya Suzuki (draftcode)（2018年6月12日）。
（由Junio C Hamano -- gitster --在commit 8d3661d中合并，2018年6月28日）
builtin/send-pack：填充默认配置
builtin/send-pack没有致电git_default_config，因此git push --signed不尊重其中gitconfig中的用户名和电子邮件 HTTP传输。