Git 如何在交互重基挤压后保留提交gpg签名？

当我想通过交互式

重基
挤压一些提交时：

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签名？
这样做没有意义。gpg签名的全部目的是验证代码没有被篡改。如果你能在修改历史记录后保留签名，那将破坏整个目的

我目前没有用gpg签署我的Git代码，所以我不知道确切的细节，但我想它可能会散列树的最终提交对象。当你像在你的例子中那样重新基址时，
最终提交
将有一个不同的sha1 ID，因此它与重新基址之前不是同一个对象，所以拥有相同的gpg签名可能是不可能的，就像我说的，这是没有意义的。
像Cupcake所说的，你不能保留未取消基址提交的旧签名，但是，如果按如下方式重新设置基础，则可以签署新的压缩提交：

git-rebase--interactive--gpg-sign=myemail@example.com标题~4

添加
--gpg符号=myemail@example.com
作为一个参数，将对最终压扁的提交进行签名。
为了强调一个事实，即您没有在重基提交上保留签名，git 2.9.x+（2016年第3季度）将明确声明a不会检查签名（因为重基部分将丢失签名）

参见（2016年5月20日）作者。

（于2016年6月20日被合并）

pull
：在
上发出警告--使用
重新设置基址来验证签名
git pull
在
运行<代码>--重新基址
，可能会让用户相信
rebase操作将检查有效的GPG签名

实现
——为
git-rebase
验证签名，
但对有效工作流程的质疑也随之产生。因为你经常合并
别人的分支进入你的分支你可能有兴趣
他们一方有有效的GPG签名

另一方面，重定基址是在
别人的工作，为了把结果推回去，为时已晚
拒绝他们的工作，即使你认为他们的承诺是可以接受的
签名

让我们警告用户，
--verify signatures
选项被忽略
在“
pull--rebase
”期间用户不想知道如果
他们的提交缺少可接受的签名

一个选项是将
commit.gpgSign
设置设置为
true
。这将始终对提交（包括重定基础的提交）进行签名

要在回购协议中在本地进行：

git config commit.gpgSign true

要在全球范围内做到这一点：

git config --global commit.gpgSign true

我希望我能放弃更多的选票！简单易用！非常感谢。这在git 1.8.3.1或更高版本中仍然是最新的吗？运行此命令会引发以下错误：
错误：未知选项“gpg符号”=me@example.com“
@jflory7我使用的是git 2.13.3，这对我来说仍然有效。如果这不起作用，你可以做一个
git-rebase-I HEAD~4
并用
git-commit--amend-S
编辑每个提交。如果它们是你的提交，这很有意义，你想保留一个签名（而不是签名）。@AndyHayden那么你应该放弃提交。它在概念上帮助我在重新设定结帐日期之前结帐一个新分支。我正在做第01号工作。我做
git结帐工作-02
。我会根据需要重新设置基础、解决合并冲突和挤压提交。work-01一点也没有改变。所有的承诺都仍然在那里，并保持原样。有些提交可能也存在于work-02中，有些可能几乎相同，但如果一个字符发生了更改，它会有一个新的提交哈希id。这个练习帮助我理解git的重定基址。这很有趣，但我想知道它是否100%有效。我们在功能分支上工作，我们的Gitlab配置为仅在可以快进（准线性历史）的情况下才允许MRs，因此，如果基本分支中发生了变化，我们将重新设置这些分支的基础。当我提交到feature branch并对提交进行签名时，我的同事会对branch进行重定，如果在没有更改的情况下选择提交，则GPG签名应该保持不变（因此我的签名仍然有效，因为它正是我提交并签名的代码）。然而，当其他人重新设置已签名提交的基础时（我们刚刚检查过），GPG签名会丢失。“所有这些提交都有相同的签名”这没有任何意义。您可能正在从同一密钥生成不同的签名，但签名本身不能相同。