交互式变基压缩后如何保留提交gpg签名？

Question

当我想通过交互式压缩一些提交时

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 签名？

Answer 1

就像 Cupcake 所说，你不能保留未压缩提交中的旧签名，但是如果你像这样重新设置基础，你可以签署新的压缩提交：

git rebase --interactive [email protected] HEAD~4

添加

[email protected]

作为参数将签署最终压缩的提交。

Answer 2

你能够做到这一点是没有意义的。 gpg 签名的全部目的是验证代码未被篡改。如果你可以在修改历史记录后保留签名，那就达不到目的了。

我目前没有使用 gpg 签署我的 Git 代码，所以我不知道确切的细节，但我猜它可能会哈希树的最终提交对象。当您像示例中那样进行变基时，

Final commit

将具有不同的 sha1 ID，因此它与变基之前不是同一对象，因此具有相同的 gpg 签名可能是不可能的，就像我说的，它不会使感觉。

Answer 3

一个选项是将

commit.gpgSign

设置设置为

true

。这将始终对提交进行签名，包括重新定位的提交。

要在存储库中本地执行此操作：

git config commit.gpgSign true

在全球范围内进行：

git config --global commit.gpgSign true

Answer 4

为了强调您不保留 rebase 提交签名的事实，git 2.9.x+（2016 年第 3 季度）将明确声明

git pull --rebase

不会检查签名（因为 rebase 部分会丢失它们）

请参阅 commit c57e501（2016 年 5 月 20 日），作者：Alexander Hirsch (``)。
^{（由 Junio C Hamano --}

gitster

-- 合并于 commit 73bc4b4，2016 年 6 月 20 日）

pull

：使用

--verify-signatures

 警告 

--rebase

git-pull

默默地忽略

--verify-signatures

选项 运行

--rebase

，可能会让用户相信 变基操作将检查有效的 GPG 签名。

讨论了为

--verify-signatures

实施

git rebase

， 但对有效工作流程的质疑不断增加。因为你通常会合并 别人的分支到你的分支你可能有兴趣 他们这边有有效的 GPG 签名。

另一方面，

Rebasing，是在之上重建你的分支 别人的工作，为了把结果推回来，已经太晚了 即使你发现他们的承诺不可接受，也要拒绝他们的工作 签名.

让我们警告用户

--verify-signatures

选项被忽略 在“

pull --rebase

”期间； 用户不会想知道如果 这样他们的提交就缺乏可接受的签名。

Answer 5

有一种方法尚未提及，但实际上它相当于在每个要签名的提交上使用

edit

进行交互式变基，以及手动修改/提交（使用

-S

），但使用预定命令并以自动方式：

git rebase --exec 'git commit --amend --no-edit -S' HEAD~3

根据

文档

，

-i

（

--interactive

）隐含于给定的--exec，因此上面没有给出。

在这里，我们针对问题中的

HEAD~3

以及每个提交进行

git commit --amend --no-edit -S

变基。这通常应该要求一次 PGP 密钥的密码，然后匆忙完成剩余的提交。

---

可以说，当您尚未全局配置时告诉 Git 进行签名，您也可以在通过

git -c commit.gpgSign=true

传递的命令中使用

--exec

（或其他相关配置选项）。