如何在Azure DevOps中同时合并两个相互依赖的PR？

针对两个分属不同仓库、互相依赖的PR（PR-A和PR-B）无法单独验证合并的问题，以下是几种可落地的解决方案：

方案一：临时分支搭桥法 #

• 给PR-B的目标仓库创建一个临时分支（比如temp/pr-b-deps），将PR-B的代码合并到该临时分支。
• 修改PR-A仓库的依赖配置（如package.json、go mod、submodule路径等），将原本指向PR-B正式分支的依赖改为指向这个临时分支。
• 提交PR-A的修改，此时CI会拉取PR-B临时分支的代码完成构建和验证，无需等待PR-B合并。
• 待PR-A的CI验证通过后，先合并PR-B到其仓库的正式分支。
• 最后更新PR-A的依赖配置，改回PR-B的正式分支，重新触发CI验证，确认无误后合并PR-A。

方案二：本地预合并+快速批量合并 #

• 在本地拉取两个仓库的最新正式分支，分别将PR-A和PR-B的代码合并到对应的本地分支中。
• 在本地环境运行完整的构建、测试流程，确保两个修改组合后功能正常、无报错。
• 确认本地验证通过后，快速连续合并：先合并PR-B到正式分支，立刻合并PR-A（尽量缩短中间窗口，避免其他提交插入导致冲突）。
• 合并完成后，立即触发两个仓库的CI重新验证合并后的代码，确保线上环境正常。

方案三：CI流程临时依赖PR分支 #

• 修改PR-A的CI脚本，在构建前添加步骤：拉取PR-B的仓库并切换到PR-B的分支，替换掉原本依赖的正式分支代码（比如通过覆盖依赖目录、修改依赖指向等方式）。
• 触发PR-A的CI，此时CI会基于PR-B的最新代码完成验证，无需PR-B先合并。
• 待PR-A和PR-B各自的CI都验证通过后，先合并PR-B到正式分支。
• 更新PR-A的CI脚本回退到原本的依赖配置，重新触发CI验证，确认无误后合并PR-A。

注意事项 #

• 若团队协作，提前告知其他成员当前的PR依赖情况，避免期间提交冲突代码。
• 准备回滚预案：合并后若出现问题，可快速回滚到合并前的状态，或保留临时分支用于排查。
• 优先选择对现有流程改动最小的方案，比如临时分支法通常适配大多数依赖场景。

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