当我想通过交互式压缩一些提交时rebase：
git rebase -i HEAD~3
进而：
pick cbd03e3 Final commit (signed)
s f522f5d bla-bla-bla (signed)
s 09a7b7c bla-bla (signed)
# Rebase c2e142e..09a7b7c onto c2e142e
...
尽管所有这些提交都具有相同的签名，但最终提交没有 gpg 签名。交互式变基壁球后是否可以保留提交 gpg 签名？
就像 Cupcake 所说，您不能保留未压缩提交的旧签名，但如果您像这样重新设置基准，则可以签署新的压缩提交：
git rebase --interactive --gpg-sign=myemail@example.com HEAD~4
添加--gpg-sign=myemail@example.com作为参数将签署最终压扁的提交。
你能做到是没有意义的。gpg 签名的全部意义在于验证代码没有被篡改。如果您可以在修改历史记录后保留签名，那将破坏整个目的。
我目前没有用 gpg 签署我的 Git 代码，所以我不知道确切的细节，但我猜它可能会散列一棵树的最终提交对象。当您像示例中那样重新设置基准时，Final commit将具有不同的 sha1 ID，因此它与重新设置基准之前的对象不同，因此可能不可能拥有相同的 gpg 签名，就像我说的那样，这没有任何意义。
为了强调您不会在 rebase 提交上保留签名的事实，git 2.9.x+（2016 年第三季度）将明确声明 agit pull --rebase不会检查签名（因为 rebase 部分会丢失它们）
请参阅Alexander Hirsch (``)的提交 c57e501（2016 年 5 月 20 日） 。（由Junio C Hamano 合并 -- --在73bc4b4 提交中，2016 年 6 月 20 日）
gitster
pull--verify-signatures:警告--rebase
git-pull运行时默默地忽略该--verify-signatures选项--rebase，可能会让用户相信变基操作会检查有效的 GPG 签名。讨论了实现
--verify-signaturesforgit rebase，但对有效工作流程的怀疑上升了。由于您通常将其他分支合并到您的分支中，因此您可能会对他们的一方具有有效的 GPG 签名感兴趣。另一方面，变基是在其他人的工作之上重建您的分支，以便将结果推回，即使您发现他们的提交缺乏可接受的签名，也为时已晚。
让我们警告用户该
--verify-signatures选项在“”期间被忽略pull --rebase；用户不会想知道如果他们的提交以这种方式缺少可接受的签名会发生什么。
一种选择是将设置commit.gpgSign设置为true。这将始终签署提交，包括重新提交的提交。
要在仓库中本地执行此操作：
git config commit.gpgSign true
要在全球范围内执行此操作：
git config --global commit.gpgSign true