我最近了解了签名提交，并且推荐使用它们。我们可以使用git commit -S 在本地签署提交。之后我阅读了 git 手册页，有一个名为 -s 的选项（用作 git commit -s），它说该选项签署了提交。当我查看 -S 时，它说它使用 GPG 密钥签署了提交。
我正在 GitHub 中使用 GPG 密钥设置签名提交。这在推送时会有所不同，还是在推送到远程时相同？
【问题讨论】：
-s 是 --signoff 的简写）
--signoff和-S有什么区别
标签： git git-commit git-sign
-s/--signoff的实际描述是：
在提交日志消息的末尾添加由提交者签名的行。 签核的含义取决于项目，但它通常证明提交者有权提交这项工作在同一许可下进行，并同意开发者原产地证书（有关更多信息，请参阅http://developercertificate.org/）。
如上所述，它基本上在提交消息的末尾添加了“Signed-off-by:”行，如下所示：
$ git log
commit 172ccc467d2171b645bb55d51146af82ac36d356 (HEAD -> master)
Author: gino <my@email.com>
Date: Sun Nov 15 11:56:10 2020 +0900
Added something
Signed-off-by: gino <my@email.com>
您可以将其理解为“我批准了提交并对此负责”。这篇相关文章已经很好地回答了它的目的：What is the Sign Off feature in Git for?。它主要是一种基于项目特定的向提交分配责任的方式，正如该帖子中的 accepted answer 所提到的，当提交的版权或许可相关时，这是必需的。
但由于它只是提交消息的一部分，任何人都可以添加/编辑它，实际上您可以通过手动输入或使用提交消息模板自己添加它。你甚至可以把别人的名字/电子邮件放在那里。在 Github 上，它将与任何其他多行提交消息一样被处理：
... 并且 Github 不会根据签名行验证提交或显示任何 UI 指示“此提交已被批准”。这当然违反了作为签核目的的 DCO，并且您可以使用插件/机器人来为 PR 强制执行它，例如 probot/dco。
另一方面，-S/--gpg-sign 选项是一个实际的加密签名，因为它使用 your 上生成的 your GPG 密钥 you > 你进行提交的机器，然后Github使用你给它的你的公钥来验证提交确实来自您（或来自拥有您的 GPG 密钥的来源）。正如Github docs on signing commits 所说：
使用 GPG 或 S/MIME，您可以在本地签署标签和提交。这些标签或提交在 GitHub 上被标记为已验证，因此其他人可以相信更改来自受信任的来源。
如果提交或标记具有无法验证的签名，GitHub 会将提交或标记标记为未验证。
存储库管理员可以在分支上强制执行所需的提交签名，以阻止所有未签名和验证的提交。
使用 -S 签名并由 Github 正确验证的提交将显示“已验证”指示器：
请务必按照他们在GPG commit signature verification 上的步骤操作。 Github 将使用它来：
在验证签名时，我们提取签名并尝试解析其 key-id。我们将 key-id 与上传到 GitHub 的密钥进行匹配。在您将 GPG 密钥上传到 GitHub 之前，我们无法验证您的签名。
至于使用哪一个，这取决于你在 Github 上放了什么以及你“签署提交”的目的是什么。如果您只是想表明实际上是 您（或您的一台机器/机器人）推动了该提交，我会说使用 GPG 密钥签名更有意义。
【讨论】：
-S（--gpg-sign 的缩写）使用 gnupg 签署您的提交，并为其添加 PGP 签名。这是一个加密签名，证明 gpg 密钥的所有者或有权访问它的参与者正在提交/标记
-s（--signoff 的缩写）将“Signed-off-by: Username<Email>”添加到提交消息的末尾。任何人都可以将此字符串放在提交消息中（因此它不能保证作者身份），但它已被用于维护版权。一些项目需要DCO“开发者原产地证书”——本质上是开发者已经证明他们有权贡献代码的证明
【讨论】：