Azure DevOps中Cherry Pick后源分支仍显示已合并PR问题咨询
核心原因是：Cherry Pick是复制提交，而非真正的分支合并，Git无法识别你已经通过Cherry Pick把部分变更同步到了Release分支。具体细节如下：
1. Git判断“已合并”的逻辑
Git靠两个核心点识别分支间的已合并提交：
- 提交的唯一哈希值：每个提交都有专属的SHA-1哈希，Git只认这个标识，不认内容是否相同。
- 分支的父子关系：只有当一个分支的提交被直接合并（比如
git merge）或变基（git rebase）到目标分支时，Git才会标记这些提交为“已合并”。
你用Cherry Pick把Dev上的5个提交放到Release时，相当于在Release分支生成了5个全新的提交——内容和Dev上的原提交一致，但哈希值完全不同。Dev上的原提交依然存在，Git自然会认为这些原提交还没被合并到Release。
2. PR状态的计算逻辑
PR的“待合并”状态是基于源分支（Dev）和目标分支（Release）的提交差异对比。因为Dev上的那5个原提交没有被真正合并到Release，对比时这些提交依然属于Dev有但Release没有的内容，所以PR列表会显示全部10个待处理项。
解决方法（达到仅显示剩余5个PR的预期）
方法一：把Release分支合并回Dev
执行git checkout dev，再git merge release。Git会自动关联Release里的Cherry Pick提交和Dev里的原提交，后续再对比Dev和Release时，就会识别出那5个原提交已经通过间接合并完成，不会再显示为待合并。
方法二：用Rebase处理剩余提交
如果团队允许修改提交历史，可以执行git checkout dev，再git rebase release。这会把Dev上剩余的5个提交移到Release分支的最新提交之后，此时再创建PR到Release，就只会显示这5个未处理的提交。
方法三：手动关闭已处理的PR（不推荐）
直接在PR平台手动关闭那5个已经Cherry Pick的PR，并备注“已通过Cherry Pick同步到Release”。但这种方式依赖人工操作，容易遗漏或出错，仅适合临时应急。
额外建议
Cherry Pick适合单个紧急修复的跨分支同步，不适合分批合并分支。如果需要分批把Dev的变更合并到Release，更合理的方式是：
- 把要优先合并的PR先合并到一个临时分支（比如
dev-staging） - 再把临时分支合并到Release，这样Git能正确追踪合并状态，后续PR只会显示未合并的内容。
内容的提问来源于stack exchange，提问作者Shashi
