有没有办法用 gpg 签署 git 提交？使用标签非常简单(使用 -s 而不是 -a)，似乎提交也有类似的功能。

最佳答案

注意:始终添加 -S 选项可能很麻烦。
在 git 2.0 及更高版本中，您可以添加一个配置来为您处理该选项。

参见 commit 2af2ef3通过 Nicolas Vigier (boklm) :

添加 commit.gpgsign 选项来签署所有提交

If you want to GPG sign all your commits, you have to add the -S option all the time.
The commit.gpgsign config option allows to sign all commits automatically.

commit.gpgsign

A boolean to specify whether all commits should be GPG signed.
Use of this option when doing operations such as rebase can result in a large number of commits being signed. It may be convenient to use an agent to avoid typing your GPG passphrase several times.

作为Apteryx评论 below :

To set this globally on the command line:

git config --global commit.gpgsign true

在 Git 2.27(2020 年第 2 季度)中，“git rebase”学习了“--no-gpg-sign”选项来反制 commit.gpgSign 用户可能有。

参见 commit 5c5bac1 , commit 4369d3a , commit 9da37fe , commit ae06ba6 , commit cf0ad4d , commit c241371 (2020 年 4 月 3 日)Đoàn Trần Công Danh (``) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit fc3f6fd ，2020 年 4 月 22 日)}

cherry-pick/revert: honour --no-gpg-sign in all case

^{Signed-off-by: Đoàn Trần Công Danh}

{cherry-pick,revert} --edit hasn't honoured --no-gpg-sign yet.

Pass this option down to git commit to honor it.

请注意，“git rebase --rebase-merges”^{( man)} 没有正确地将 --gpg-sign 命令行选项传递给底层的“git merge” 当使用非默认 merge 策略重放 merge 或重放 Octopus merge 时(因为使用默认策略重放双头 merge 是在单独的代码路径中完成的，大多数用户不会触发该问题)，其中已使用 Git 2.30(2021 年第一季度)进行更正

参见 commit 43ad4f2 , commit 19dad04 , commit ae03c97 (2020 年 10 月 18 日)Samuel Čavoj (sammko) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 73af6a4，2020 年 11 月 2 日)}

sequencer: fix gpg option passed to merge subcommand

^{Signed-off-by: Samuel Čavoj}

When performing a rebase with --rebase-merges using either a custom strategy specified with -s or an octopus merge, and at the same time having gpgsign enabled (either rebase -S or config commit.gpgsign), the operation would fail on making the merge commit.

Instead of "-S%s" with the key id substituted, only the bare key id would get passed to the underlying merge command, which tried to interpret it as a ref.

Fix the issue and add test cases as suggested by Johannes Schindelin and Junio C Hamano.

和:

sequencer: pass explicit --no-gpg-sign to merge

^{Signed-off-by: Samuel Čavoj}

The merge subcommand launched for merges with non-default strategy would use its own default behaviour to decide how to sign commits, regardless of what opts->gpg_sign was set to.
For example the --no-gpg-sign flag given to rebase explicitly would get ignored, if commit.gpgsign was set to true.

Fix the issue and add a test case exercising this behaviour.

固定在:

"git rebase --rebase-merges "^{( man )} 没有正确地将 --gpg-sign 命令行选项传递给底层 "git merge”当使用非默认 merge 策略重放 merge 或重放 Octopus merge 时(因为使用默认策略重放双头 merge 是在单独的代码路径中完成的，所以大多数用户不会触发该问题)，这已被已使用 Git 2.30(2021 年第一季度)更正，.

参见 commit 43ad4f2 , commit 19dad04 , commit ae03c97 (2020 年 10 月 18 日)Samuel Čavoj (sammko) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 73af6a4，2020 年 11 月 2 日)}

sequencer: fix gpg option passed to merge subcommand

^{Signed-off-by: Samuel Čavoj}

When performing a rebase with --rebase-merges using either a custom strategy specified with -s or an octopus merge, and at the same time having gpgsign enabled (either rebase -S or config commit.gpgsign), the operation would fail on making the merge commit.
Instead of "-S%s" with the key id substituted, only the bare key id would get passed to the underlying merge command, which tried to interpret it as a ref.

Fix the issue and add test cases as suggested by Johannes Schindelin and Junio C Hamano.

关于git - 使用 GPG 签署 git 提交，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10077996/