引言在基于Gerrit CI的研发流程中提交标题的唯一性检查是保证提交历史整洁的重要手段。然而在实际开发中我们偶尔会遇到这样一种棘手的情况两个不同作者的提交拥有完全相同的提交标题且各自独立通过了Verify CI并成功合入目标分支。当这种情况发生时后续所有新增的提交都会因为提交标题重复而触发CI的-2失败整个研发流程被彻底阻塞。作为一名DevOps或SRE工程师你很可能被叫来救火。本文将系统性地梳理这类问题的成因并给出完整的修复方案和操作步骤。一、问题场景还原1.1 问题是如何产生的在一个多人协作的项目中假设有两个开发者A和B在几乎相同的时间段内各自基于目标分支如master开发了不同的功能。由于沟通不及时或其他原因两人提交的Commit Message标题完全一致——例如都是feat: add node agent。两个提交各自通过代码评审和Verify CI后先后被合入master分支。此时master分支的历史中存在两条提交记录commit abc1234 (作者A) feat: add node agent commit def5678 (作者B) feat: add node agent提交标题相同但提交哈希、作者、代码变更内容均不相同。然而master分支上的提交历史已经出现了重复标题。1.2 CI重复标题检查机制许多团队的CI流水线中会配置提交信息规范检查其中包括提交标题去重检查。常见的实现方式是在CI脚本中提取指定范围内的所有提交标题通过sort | uniq -d检测重复项一旦发现重复即终止流程并返回-2gitlog--prettyformat:%s$range./subjectsduplicates$(cat./subjects|sort|uniq-d)if[$duplicates!];thenecho发现重复提交:$duplicatesexit1fi当master分支中已经存在重复标题时后续任何新的提交无论标题是什么只要CI脚本扫描到历史中存在重复标题就会直接失败。这意味着整个目标分支的CI门禁被永久阻塞任何新代码都无法合入。1.3 问题根源这个问题的本质是提交标题的唯一性约束本应在提交时检查但两个重复标题的提交是在不同时间、各自独立通过CI的。当第二个重复标题的提交被合入时CI只检查了当时的提交历史那时还没有重复并未预见到未来会出现重复。当两个重复提交同时存在于分支中时CI的全局检查就会触发失败。类似的场景在Gerrit中也会因重复的Change-Id导致推送被拒绝。虽然问题的具体表现略有不同但根本原因都是唯一性约束被破坏后导致后续操作被阻塞。二、修复方案全景图修复的核心思路是在保留所有有效代码变更的前提下消除重复的提交标题。这需要DevOps工程师介入手动重建分支历史。整体修复流程如下备份当前分支 → 找到最后一个OK的历史提交 → 基于该提交创建新分支 → 逐个cherry-pick需要保留的提交 → 处理冲突 → 推送新分支 → 通知团队切换三、详细操作步骤3.1 第一步锁定目标分支防止新的合入在开始修复之前必须确保没有新的提交被合入目标分支否则修复工作将变得极其复杂。# 联系团队暂停向目标分支的推送# 在Gerrit中可以考虑临时锁定分支或通过项目权限设置禁止推送3.2 第二步备份当前分支在进行任何破坏性操作之前先为当前分支创建一个备份标签或备份分支# 切换到目标分支假设为 mastergitcheckout master# 拉取最新代码gitpull origin master# 创建备份标签推荐便于回溯gittag backup/master-$(date%Y%m%d-%H%M%S)# 或创建备份分支gitbranch backup/master-before-fix3.3 第三步查找历史中最后一个健康的提交所谓健康的提交是指在该提交时刻目标分支的提交历史中不存在重复的提交标题。通常这是两个重复提交中较早合入的那一个的前一个提交。# 查看提交历史定位问题提交gitlog--oneline--graph-20# 或使用更详细的方式查看提交标题gitlog--prettyformat:%h %an %s-20假设提交历史如下abcd123 (最新) 作者B feat: add node agent ← 第二个重复提交 efgh456 作者A feat: add node agent ← 第一个重复提交 ijkl789 作者C fix: memory leak ← 最后一个健康的提交那么ijkl789就是我们需要的健康基点。3.4 第四步基于健康提交创建新分支# 基于健康提交创建新分支gitcheckout-bmaster-fix ijkl789这里git checkout -b 新分支名 起始点表示从指定的提交创建一个新分支并切换过去。此时master-fix分支的代码状态与ijkl789时刻完全一致不包含任何重复提交。3.5 第五步使用cherry-pick逐个恢复需要保留的提交现在需要将健康提交之后的所有有效提交逐个应用到新分支上。Cherry-pick的作用正是从一个分支中挑选特定的提交并应用到当前分支。# 列出健康提交之后的所有提交gitlog--onelineijkl789..master# 逐个cherry-pick注意跳过会导致重复的提交# 假设需要保留的提交有mnop012、qrst345、abcd123第二个重复提交# 但我们需要修改第二个重复提交的标题gitcherry-pick mnop012gitcherry-pick qrst345关键操作当cherry-pick到第二个重复提交abcd123时我们需要修改其提交标题以消除重复。# 使用 -e 选项在cherry-pick时编辑提交信息gitcherry-pick-eabcd123此时会弹出编辑器将提交标题从feat: add node agent修改为feat: add node agent (fix author B)或其他不重复的标题。注意由于abcd123已经被cherry-pick过来它会生成一个新的提交哈希与原始提交不同。3.6 第六步处理可能的冲突如果在cherry-pick过程中遇到冲突Git会暂停操作# 查看冲突状态gitstatus# 手动解决冲突后gitadd.gitcherry-pick--continue如果冲突无法解决或发现某个提交不应该被保留可以使用以下命令放弃当前操作gitcherry-pick--abort3.7 第七步验证新分支在新分支上执行完整的验证# 确认提交历史中没有重复标题gitlog--prettyformat:%s|sort|uniq-d# 确认代码编译通过makebuild# 或项目对应的编译命令# 确认所有需要的提交都已恢复gitlog--oneline3.8 第八步推送新分支并替换原分支# 推送新分支到远程gitpush origin master-fix# 在Gerrit中需要强制推送以替换原有的master分支# 注意此操作需要管理员权限gitpush-forigin master-fix:master3.9 第九步通知团队并解封分支修复完成后通知团队成员分支已修复可以继续开发解除分支锁定建议团队成员重新基于最新的master分支拉取开发分支四、完整的操作命令汇总以下是整个修复过程的命令速查# 1. 备份gitcheckout mastergitpullgittag backup/master-before-fix# 2. 查找健康提交gitlog--oneline--graph-20# 3. 创建新分支gitcheckout-bmaster-fix健康提交哈希# 4. 逐个cherry-pick需要保留的提交gitcherry-pick提交1gitcherry-pick提交2gitcherry-pick-e重复提交# 编辑标题以消除重复gitcherry-pick提交N# 5. 处理冲突如有gitstatus# 解决冲突后gitadd.gitcherry-pick--continue# 6. 验证gitlog--prettyformat:%s|sort|uniq-d# 7. 推送gitpush-forigin master-fix:master# 8. 清理确认一切正常后gitbranch-dmaster-fix五、预防措施为了避免此类问题再次发生建议采取以下措施CI检查时机优化将提交标题去重检查的范围限定为当前提交及之前N个提交而非全量历史避免因历史遗留问题阻塞新提交提交时实时检查利用Git hookspre-commit或pre-push在本地提交时就检查提交标题是否与远程分支已有提交重复代码评审环节把关在Gerrit的代码评审中要求评审者检查提交标题是否与已有提交重复规范提交标题格式强制要求提交标题包含功能模块或Issue编号从源头降低标题重复的概率建立监控告警定期扫描目标分支的提交历史发现重复标题时及时告警避免问题积累六、总结提交标题重复导致CI阻塞是一个典型的历史遗留问题引发的连锁反应。虽然问题本身不复杂但修复过程需要DevOps工程师具备扎实的Git操作能力尤其是对cherry-pick、checkout -b等命令的熟练运用。git cherry-pick的核心价值在于能够从复杂的提交历史中精确地挑选需要的提交而不会引入不需要的变更。在分支修复场景中它正是我们精确重建分支历史的关键工具。作为DevOps工程师面对此类问题时应保持冷静先备份、再定位、后重建、终验证。只要遵循这一原则大多数分支历史问题都能得到安全、可靠的解决。