关于github:Github的一个奇技淫巧

背景

前段时间给 VictoriaLogs 提交了一个 PR：
https://github.com/VictoriaMetrics/VictoriaMetrics/pull/4934

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

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

以前我也没怎么留神过这个选项，通过 Google 后发现 Idea 在提交的时候能够自行设置。

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

为 GitHub 的提交签名

联合这位社区大佬给的文档，他所须要的是每次提交的代码都是有签名的，相似于这样：

如果咱们想要 GitHub 事实 Verified 这个标签，那就须要对 commit 或者是打的 tag 进行签名。

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

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

gpg --full-generate-key

应用这个命令生成 key，之后会依据提醒录入一些信息，蕴含你的 ID 和邮箱，倡议都和 GitHub 的 ID 邮箱保持一致即可，而后一路回车完事。

之后能够应用这个命令查看方才创立的 Key：

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 字符串复制，之后执行：

gpg --armor --export 3AA5C34371567BD2
# Prints the GPG key ID, in ASCII armor format

此时会打印出公钥，咱们将

-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----

这些数据复制到 GitHub 的集体设置页面：

此时还没完，如果咱们间接提交代码的也不会有 Verified 的标签。

咱们还须要关上 git 的 config 设置：

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 的成果一样。

官网文档也有具体的步骤：
https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification

Squash 合并提交

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

最终成果如下，只有一个 Commit 存在。

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

以方才测试的这两个提交为例，我须要将他们合并为一个提交。

咱们先应用这个命令：

git rebase -i HEAD~N
git rebase -i HEAD~2

N 就是咱们须要合并几个提交，在我这里就是 2.

咱们须要将除了第一个 commit 之外的都批改为 s，也就是上面正文里的 squash 的简写（压缩的意思）。

这是一个 vim 的交互编辑模式，编辑实现之后保留退出。

不会还有程序员不晓得如何保留 vim 退出吧🐕。

保留后又会弹出一个编辑页面，让咱们填写这次压缩之后的提交记录，默认会帮我生成好，当然你也能够全副删掉后重写。

我这里就间接应用它生成好的就能够了，仍然还是保留退出。

最初再强行推送到我所在的分支即可：

git push origin test-rebase -f

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

总结

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