Azure DevOps能否处理基于其他功能分支变基后的拉取请求？

能否基于同事的分支执行变基？ #

当然可以，操作流程很直接：

• 先拉取同事的分支到本地：git fetch origin <同事分支名>
• 切换到你的分支：git checkout <你的分支名>
• 执行变基：git rebase origin/<同事分支名>
• 处理变基过程中出现的冲突，完成后推送到远程。如果你的分支之前已经推过，需要用安全强制推送：git push --force-with-lease origin <你的分支名>，这个参数比单纯--force更稳妥，能避免覆盖他人未同步的修改。

两种场景下你的PR在Azure DevOps的状态 #

场景1：同事的PR合并到main分支 #

等同事的PR合并后，你的分支里会包含和main重复的提交。这时候你需要把自己的分支重新变基到最新的main上：

• 拉取最新main分支：git fetch origin main
• 变基到main：git rebase origin/main
• 解决可能的冲突后推送（同样可能需要--force-with-lease）
• Azure DevOps会自动更新你的PR，同步目标分支的最新状态，你的PR可以正常继续审核和合并，不会有任何问题。

场景2：同事放弃该PR #

如果同事放弃了他的PR，也就是他的分支不会被合并到main，那你的分支里会保留他未被合并的代码：

• 如果你依然需要这些功能，你的PR完全可以正常提交，只要你的分支通过审核、CI验证没问题，就能合并到main，Azure DevOps会正常处理整个流程。
• 要是后续你不需要这些功能了，可以用交互式变基（git rebase -i origin/main）把来自同事分支的提交从你的分支里移除，推送更新后，PR也能正常调整。

几点注意 #

• 变基后推送远程分支时，一定要用--force-with-lease，别用--force，防止误操作覆盖他人的修改。
• 要是你的PR已经有审核评论，变基推送后Azure DevOps会保留这些评论，只是会关联到新的提交哈希，不影响审核进度。
• 操作前最好和同事打个招呼，避免双方同时操作分支导致不必要的冲突。

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