为什么我就想要「线性历史 + Signed Commits」，GitHub 却把我当猴耍 ️

【开场】

欢迎收听今天的节目。
今天主题很简单，也很不人类——我他妈就只想要两件事。
第一，主分支历史是线性的。git log 打开来，我看的是一条时间线，不是在读心电图找节奏，不是在欣赏抽象画，就他妈是一条直线。
第二，我的每个提交都是我本人签的。GitHub 上给我乖乖显示绿色 Verified，不要动不动整成灰扑扑的 Unverified，看着像犯罪现场，像我交了一份伪造证据。
就这两件事，说出来一句话都不到。
然后 GitHub 端着一张"工程最佳实践代言人"的臭脸，递给你三个按钮：Merge、Squash、Rebase。
你以为你在选合并策略。
你他妈其实是在选——签名以哪种姿势死去。
【第一段：先把真相拍你脸上，别怪我没说】

在骂那三个按钮之前，有一件事得先讲清楚，不然后面你会听得一头浆糊。
签名签的不是「改动内容」，签的是「commit 这个对象本身」。
commit 对象里装的东西，远不止你改了哪些文件。还有：父提交是谁、作者是谁、提交者是谁、时间戳是几点几分几秒。
你但凡动了里头任何一个字段——哪怕就换了个提交者名字，哪怕就多了一毫秒的时间戳偏差——这他妈就不是同一个 commit 了。SHA 会变，建立在旧 SHA 上的签名，直接废了，不留情面，不接受解释。
换句话说：你以为你签的是「代码」，你他妈实际签的是「这坨数据的身份证」。身份证号换了，原来那张验证复印件就是一张废纸，扔了吧。
数学不讲情面，Git 更不讲。
把这个刻脑子里，后面你才能看懂 GitHub 到底在对你干什么。
【第二段：三个按钮，用「签名视角」逐个解剖】

好，现在我们来看 GitHub 给你的那三个「选择」。
为什么每一个都像在嘲笑你，为什么每一个都在用不同方式把你的签名送走。
① Create a merge commit — 老派，但起码他妈没在骗你

这是最传统的方式，也是最诚实的方式。
它不重写你 PR 分支上的提交。你那些 commits 还是原来那些 commits，SHA 不变，签名大概率也就还活着。
代价是什么？主分支历史出现一个 merge 节点，不线性，git log 看起来像蜘蛛网。
GitHub 这时候语重心长地说：你不是想要线性历史吗？那你别用这个哦。
行，人类想要「干净」，就得先交出一样东西。我他妈到底在做什么取舍？
② Squash and merge — 产品经理最爱，签名最大的幻觉

这个方式非常「表面和谐」：把你 PR 里一串 commits 全揉成一个新提交，主分支线性，历史干净，看起来什么坏事都没发生过。
然后你发现那个 squash commit 上还挂着绿色 Verified。
你一激动，以为签名保住了，以为事情没那么糟。
醒醒，你他妈被哄了。
那个 Verified 往往是 GitHub 给它自己新造出来的那个 commit 盖的章。不是「保留了你的签名」，是「我帮我自己签了一个，顺便把你的全扔掉了，你慢慢玩」。
你原来那一串提交根本没进 main，它们签没签，对主分支来说已经是前任的故事，不重要了，随它去吧。
GitHub 在帮它自己 Verified，然后把这个绿勾勾展示给你看，你还在那感激涕零。
③ Rebase and merge — 线性历史的诱惑，签名最大的坟场

这是三个里面最阴险的一个，没有之一。
它看起来完美满足你的线性洁癖——把 PR 里每个 commit 在 main 顶端重放一遍，一条直线，漂亮，优雅，干净。
然后你去看每个「重放出来的」commit：SHA 全变了。

1. 新 commits = 新 SHA
2. 新 SHA     = 旧签名直接作废

复制代码

就这么简单，就这么操蛋。
你可能要问：我他妈明明已经提前把分支 rebase 到 main 最新 HEAD 了，为什么 GitHub 按那个按钮还要改我的 SHA？
因为它按下去的时候，根本不是在「尊重你已经做好的工作」。它走的是自己内部的一套 rebase 流程，重建对象、更新 committer 元数据，不管你之前做没做过，到它手里，SHA 一律重造，你之前的努力，当它没发生过。
签名丢了还不算完。最他妈绝的是：GitHub 没有你的私钥。
它没法替你把那串新 commits 重签。能力不够，没有办法，爱莫能助。它能做的就是挂一个冷冰冰的 Unverified 上去，再配合 vigilant mode，给你贴一个「可疑提交」的标签，像给你挂了个嫌疑人胸牌。


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！