Git同内容不同SHA1的重复提交：根因、预防与修复方案

重复提交的产生根因 #

首先要明确：Git的提交SHA哈希值并非只匹配代码改动，它是对提交全量信息做哈希计算的结果，计算维度包括代码差异、父提交哈希、提交者信息、提交时间、提交说明。只要上述任意一个维度的信息存在差异，哪怕代码改动、提交说明、作者时间完全一致，最终生成的SHA也会完全不同。
结合当前的拓扑状态，在多人协作的公共仓库里，这类同内容、不同SHA的平行提交，通常由以下几种操作触发：

• 最常见的触发场景：某段提交最初是在feature分支上开发的，后续某次合并操作没有通过正常的merge接续历史，而是通过cherry-pick把这几个提交单独搬到了develop分支上。两次提交的父节点不一样，哪怕其他信息完全一致，最终生成的SHA自然不同。
• 第二高频场景：某次协作用git rebase重写了分支历史，且开启了--committer-date-is-author-date参数。这个参数只会保留原提交的作者时间，会自动用当前系统时间覆盖提交者时间戳，直接改写所有涉及提交的SHA。如果之后把重写后的分支强推到远端，和之前没被重写的同名分支做合并，就会出现同内容、同作者时间，但提交人时间不同、SHA不同的平行提交。
• 第三类常见场景：合并时混用了不同的合并模式。比如把feature分支的代码用git merge --squash压缩成单个新提交合入develop，没有保留原来的提交链；之后两个分支分别继续开发，各自在自己的提交基础上叠加新改动，时间一长就会形成代码逻辑完全对应、但SHA完全不一样的平行提交序列。
• 少数场景来自协同流程漏洞：不同开发者从同一个公共基线拉分支，独立做了完全一样的代码改动、写了完全一致的提交说明、填了一样的提交时间，分别推送到不同的分支引用下，因为提交者的用户名/邮箱信息不同，最终生成的SHA也会不同，形成重复提交。

常见的预防措施 #

• 统一公共分支的操作红线：develop、main这类多人共用的公共分支，禁止直接在上面做rebase、强制推送类的历史改写操作，所有历史更新必须通过正常merge流程追加，不能随意修改已经推到远端的公共提交。
• 统一分支合并标准：跨分支合并时固定使用同一种合并模式，不要在同一个仓库里同时混用fast-forward、--no-ff合并、squash合并、cherry-pick搬运等多种方式处理分支，从流程上切断不同提交路径的交叉。
• 开启服务端分支保护：通过Git平台的规则设置，禁止对受保护的公共分支执行强制推送、历史重写操作，从服务器层面阻止历史被随意篡改。
• 协同前先同步状态：每次提交新代码前，先拉取远端同分支的最新状态，避免多人基于过时的公共基线开发出重复的提交内容。

问题修正方案 #

你提出的“使用rebase操作修正”的方向是完全正确的，但需要结合分支的实际协作状态选择操作，避免引发更大的历史混乱：

• 如果这些重复提交还没有被其他协作者拉取，只存在于本地分支上：直接在feature分支上执行git rebase develop即可，Git会自动识别代码内容完全一致的提交，自动跳过重复节点，让feature分支的提交直接接续在develop的最新提交之后，拓扑就会回到理想的线性状态。
• 如果重复提交已经推送到远端，且被其他协作者拉取使用：绝对不能直接对公共分支做rebase然后强推，此时正确的操作是：拉取两个分支的最新状态，新建本地临时分支，从最早的共同基线A点开始，把两个分支上的所有有效提交按时间顺序逐个重放，过程中跳过所有内容重复的节点，生成干净的全新提交历史；之后再通过正常的PR流程把新历史合入两个目标分支，操作前需要提前通知所有协作者同步最新的分支状态，避免大家基于旧的分支历史继续开发。
• 修正过程中需要额外注意：如果这些重复提交已经对应过正式的线上版本发布，不要为了消除重复而重写历史删除这些提交，只需要保证后续合并时不再引入新的重复节点即可，避免出现线上版本和仓库提交历史对不上的问题。

内容的提问来源于stack exchange，提问作者Guillaume D