同一个修复 cherry-pick 两次 git log 出现两条不同哈希

release 分支上同一个空指针修复出现两次，提交哈希不同，diff 一模一样。后面再合主干时报冲突，两边都改过同一行。第一次遇到会往复杂处想，其实漏掉的多是个小前提。

git cherry -v main release/1.8
git show 3f2a1c9 | git patch-id --stable
git log --oneline release/1.8 --grep='空指针'

cherry-pick 每次都生成新提交，哈希变了，Git 不会认为它们是同一个改动。两个人各自从主干摘一次，或者摘完又 merge 回来，同一份补丁就进了两遍。这一点先确认清楚，后面就不用反复试。

「cherry-pick 重复补丁」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。

改完隔一天再看一次，当场正常不代表能稳住。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。

具体做法是，git cherry -v main release 看哪些提交以加号开头 已在主干的会被标成减号；git show 加 git patch-id 算补丁指纹 对比两条是否等价；多出来的那条用 git revert 撤掉 别 reset 已推送历史；后续改用 merge 或 rebase 同步 少用 cherry-pick。

改完照着核一遍，git cherry 里重复提交只剩一条 diff 不再出现同一段改动。