Azure DevOps cherry-pick合并提交提示本地解决但无冲突问题

分支结构如上图，将alpha分支变更通过cherry-pick同步到beta分支时，遇到以下异常场景：

• 故事分支1的变更在Azure DevOps经Pull Request(PR)审批通过后合并到alpha分支，alpha分支测试通过后，通过合并PR自带的cherry-pick按钮可顺利将变更拣选合并到beta分支，无任何问题。
• 故事分支2的变更提交PR合并到alpha分支时出现冲突（与故事分支1修改了相同代码行），冲突解决后对应位置的代码与beta分支当前同位置代码存在差异。此时通过Azure DevOps PR界面的cherry-pick合并功能尝试将该变更从alpha分支拣选到beta分支，收到报错：

Encountered conflicts when cherry-picking commit. This operation needs to be performed locally.

• 切换到本地beta分支执行命令：git cherry-pick -m 1 {alpha分支上故事分支2对应合并提交的hash值}，执行过程全程未提示任何冲突，直接覆盖了beta分支的原有代码。

两边冲突检测结果不一致、本地cherry-pick直接覆盖代码的根源是双方的合并计算基准不同：

1. Azure DevOps的PR cherry-pick逻辑，默认以PR源分支（即故事分支2的独立提交链）作为变更计算基准，拿故事分支2的代码、beta分支HEAD、两者的共同祖先做三方合并。由于合并故事分支2到alpha时的冲突解决结果，和beta分支当前同位置代码不匹配，因此判定存在冲突，要求本地处理。
2. 本地执行带-m 1参数的cherry-pick时，Git会将合并提交的第1个父节点（Azure DevOps生成的PR合并提交中，第1父节点是合并前的alpha分支HEAD，第2父节点才是故事分支2的HEAD）作为基线，计算「合并前alpha -> 合并后alpha」的全量diff，再把这份diff应用到beta分支。
   这份diff里不仅包含故事分支2的原生改动，还包含合并时解决冲突产生的代码调整。Git默认的自动合并逻辑判定这份diff的上下文和beta分支匹配，就会直接应用改动覆盖对应代码，不会弹出冲突提示。

不要直接拣选alpha分支上的合并提交，按以下方式操作即可对齐Azure DevOps的冲突检测逻辑，进入手动冲突解决流程：

• 优先选择直接拣选故事分支2的原生提交
  先从提交历史中找到故事分支2上所有对应本次需求的独立提交hash，切换到beta分支后执行：
  git cherry-pick <提交hash1> <提交hash2> ...
  该操作的三方合并计算逻辑和Azure DevOps完全一致，只要对应位置代码存在匹配冲突，Git会自动暂停流程，进入冲突解决状态，不会直接覆盖代码。
• 若必须拣选alpha上的合并提交，关闭Git自动合并优化
  执行cherry-pick时追加参数关闭自动合并、重命名检测等优化逻辑，强制标记所有代码不一致位置为冲突，命令如下：
  git cherry-pick -m 1 --no-ff -X no-renames <alpha分支合并提交hash>
• 拣选后增加校验步骤
  无论用哪种方式执行cherry-pick，在执行git cherry-pick --continue提交前，先运行git diff HEAD对比beta分支原有代码和当前暂存区代码，确认所有改动符合预期，避免误覆盖。

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