Github的一个奇技淫巧

背景

前段时间给 VictoriaLogs 提交了一个 PR: github.com/VictoriaMet...

本来一切都很顺利,只等合并了,但在临门一脚的时候社区维护人员问我可否给 git commit 加上签名。

于是我就默默的调试到了凌晨四点😭

以前我也没怎么注意过这个选项,经过 Google 后发现 Idea 在提交的时候可以自行设置。

当我勾选了这个提交新的代码后,依然被告知没有正确的签名,这时我才发现理解错误了。

为 GitHub 的提交签名

结合这位社区大佬给的文档,他所需要的是每次提交的代码都是有签名的,类似于这样:

如果我们想要 GitHub 现实 Verified 这个标签,那就需要对 commit 或者是打的 tag 进行签名。

而签名的方式有三种:GPG, SSH, S/MIME,这里我以 GPG 签名为例,整体流程如下:

先在www.gnupg.org/download/这里下载安装 GPG 的命令行程序。

shell 复制代码
gpg --full-generate-key

使用这个命令生成 key,之后会根据提示录入一些信息,包含你的 ID 和邮箱,建议都和 GitHub 的 ID 邮箱保持一致即可,然后一路回车完事。

之后可以使用这个命令查看刚才创建的 Key:

shell 复制代码
gpg --list-secret-keys --keyid-format=long
------------------------------------
sec   4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
uid                          Hubot <hubot@example.com>
ssb   4096R/4BB6D45482678BE3 2016-03-10

我们需要将 3AA5C34371567BD2 这个 Key 的 ID 字符串复制,之后执行:

shell 复制代码
gpg --armor --export 3AA5C34371567BD2
# Prints the GPG key ID, in ASCII armor format

此时会打印出公钥,我们将

vbnet 复制代码
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----

这些数据复制到 GitHub 的个人设置页面:

此时还没完,如果我们直接提交代码的也不会有 Verified 的标签。

我们还需要打开 git 的 config 设置:

shell 复制代码
git config commit.gpgsign true

# 全局打开
git config --global commit.gpgsign true
git commit -S -m "YOUR_COMMIT_MESSAGE"
git push

这样提交的 Commit 就会打上验证的标签了。

-S 的效果和在 idea 中选中 Sign-off 的效果一样。

官方文档也有详细的步骤: docs.github.com/en/authenti...

Squash 合并提交

不过在我这个 PR 的背景下还有一个步骤没有完成,就是我之前提交的 Commit 都没要验证,我需要将他们都合并为一个验证的 Commit 然后在强制推送上去,这样整个 git log 看起来才足够简洁。

最终效果如下,只有一个 Commit 存在。

这时候就得需要 git rebase 出马了。

以刚才测试的这两个提交为例,我需要将他们合并为一个提交。

我们先使用这个命令:

shell 复制代码
git rebase -i HEAD~N
git rebase -i HEAD~2

N 就是我们需要合并几个提交,在我这里就是 2.

我们需要将除了第一个 commit 之外的都修改为 s,也就是下面注释里的 squash 的简写(压缩的意思)。

这是一个 vim 的交互编辑模式,编辑完成之后保存退出。

不会还有程序员不知道如何保存 vim 退出吧🐕。

保存后又会弹出一个编辑页面,让我们填写这次压缩之后的提交记录,默认会帮我生成好,当然你也可以全部删掉后重写。

我这里就直接使用它生成好的就可以了,依然还是保存退出。

最后再强行推送到我所在的分支即可:

shell 复制代码
git push origin test-rebase -f

在这个分支的提交页面也只会看到刚才强行推送的记录了,刚才的两个提交已经合并为这一个了。

总结

借着这个机会也了解了 rebase 的骚操作挺多的,不过我平时用的最多的还是 merge,这个倒没有好坏之分,只要同组的开发者都达成一致即可。

相关推荐
草梅友仁34 分钟前
墨梅博客 1.4.0 发布与开源动态 | 2026 年第 6 周草梅周报
开源·github·ai编程
学电子她就能回来吗2 小时前
深度学习速成:损失函数与反向传播
人工智能·深度学习·学习·计算机视觉·github
xuhe26 小时前
[全流程详细教程]Docker部署ClawBot, 使用GLM4.7, 接入TG Bot实现私人助理. 解决Docker Openclaw Permission Denied问题
linux·docker·ai·github·tldr
先跑起来再说6 小时前
Git 入门到实战:一篇搞懂安装、命令、远程仓库与 IDEA 集成
ide·git·后端·elasticsearch·golang·intellij-idea
宇宙帅猴6 小时前
GitHub 私有仓库认证完整指南:告别密码错误,使用 PAT 令牌
github
前端市界9 小时前
用 React 手搓一个 3D 翻页书籍组件,呼吸海浪式翻页,交互体验带感!
前端·架构·github
happyprince9 小时前
2026年02月07日热门github项目
github
承渊政道9 小时前
Linux系统学习【Linux系统的进度条实现、版本控制器git和调试器gdb介绍】
linux·开发语言·笔记·git·学习·gitee
Doro再努力9 小时前
【Linux操作系统12】Git版本控制与GDB调试:从入门到实践
linux·运维·服务器·git·vim
CoderJia程序员甲10 小时前
GitHub 热榜项目 - 日榜(2026-02-06)
人工智能·ai·大模型·github·ai教程