Azure DevOps中release合并stable遇冲突，公共祖先过旧求助

一、为什么公共祖先仍是4.0.7？ #

核心原因是stable分支的4.0.9版本并非通过常规合并（merge）release分支生成，导致Git无法将其识别为两个分支的共同祖先：

• 如果之前合并release到stable时用了* squash合并*（或rebase），stable上的4.0.9会是一个全新的独立提交，而非包含release分支完整历史的合并提交。这种情况下，release分支的历史里没有4.0.9，stable分支也未包含release在4.0.7之后的完整提交链，Git计算公共祖先时自然停留在最早的4.0.7。
• 另一种可能是有人直接在stable分支上提交了修改（绕过了从release合并的流程），导致stable和release从4.0.7开始分道扬镳，公共祖先也就停在这个节点。

二、PR无合并策略选项的解决方案 #

1. 联系管理员配置分支策略 #

这是最根本的解决方法：让管理员进入Azure DevOps项目设置，依次找到Repositories -> Branches，选中stable分支的分支策略，在合并策略板块启用需要的选项（比如squash合并、rebase合并、常规合并）。配置完成后，创建PR时就会显示对应的合并策略选择项。

2. 本地临时处理方案（无需管理员操作） #

如果暂时无法等待管理员配置，可以手动在本地处理冲突后合并：

• 拉取最新的stable和release分支：

  git checkout stable
  git pull
  git checkout release
  git pull
  

• 在本地将release合并到stable，手动解决冲突：

  git checkout stable
  git merge release
  # 解决冲突后执行
  git add .
  git commit -m "Merge release into stable (resolve conflicts)"
  

• 推送到远程stable分支（需拥有stable分支的推送权限）：

  git push origin stable
  

  若没有直接推送stable的权限，可以基于本地合并后的stable创建临时分支，提交PR到stable后请管理员审核合并。

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