多次cherry-pick同一提交后合并失效，此现象是否合理？

场景还原 #

• 开发分支dev上有一个配置类提交（用于切换服务器），因需要多次复用，采用cherry-pick重新应用该提交
• 第一次cherry-pick操作正常，切换至publish分支合并dev后，修改成功生效
• 几天后重复相同流程：cherry-pick同一提交后合并至publish，但publish分支未出现对应修改
• 在测试仓库复现该现象：多次cherry-pick同一提交时，仅第一次合并会生效
• 补充场景：当他人修改相关内容并合并至master后，尝试将该提交重新应用回"test1"状态，第一次cherry-pick正常生效，第二次的cherry-pick被合并操作直接忽略

原因分析 #

Git的合并是三路合并操作，核心逻辑是对比当前HEAD、目标提交以及两者的最新共同祖先，以此判断是否存在需要合并的变更。当你的"test1"状态与dev和master的共同祖先内容完全一致时，Git会判定这次cherry-pick的修改没有相对于祖先的实质性变更，因此合并时会直接忽略该内容。

这个机制并非cherry-pick专属，但cherry-pick会提升触发该问题的概率——因为它是将旧提交的修改重复应用到不同的分支状态中，更容易出现"修改内容与共同祖先一致"的情况。

解决方案建议 #

建议通过创建新的合并基准来规避该问题：比如基于最新的目标分支（如publish或master）重新生成需要复用的提交，而非重复cherry-pick同一个旧提交。

参考资料 #

《停止使用cherry-pick，开始合并（第二部分）：从未发生的合并冲突（但本应发生）》

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