Azure中Git Pull Request工作原理及远程已删分支残留问题咨询

• 权限与规则校验：PR发起后，系统会自动校验分支读写权限、匹配仓库配置的强制策略（比如必选评审人数量、流水线运行结果、提交信息格式要求），所有校验通过后才允许执行合并操作。
• 变更追踪：PR创建时会自动关联源分支当前的提交记录，对比目标分支的历史提交生成差异列表，可关联对应工作项追踪开发进度。
• 合并执行：根据用户选择的合并策略（如你使用的Rebase and fast-forward），将源分支的提交按顺序追加到目标分支的提交链路上，生成符合规范的提交历史。
• 收尾操作：合并完成后，若勾选「删除源分支」选项，系统会在Azure Repos的服务端仓库侧直接移除对应源分支的访问入口，网页端展示的分支列表会实时同步这个删除结果。

这个问题的核心是Git本地的远程分支引用是本地缓存快照，并非和服务端实时同步的动态数据：

• 你在本地克隆仓库、推送代码、拉取代码的过程中，Git会把当时服务端所有远程分支的指向信息存储在本地的.git/refs/remotes/origin/目录下，相当于留存了一份远程分支状态的本地副本。
• 只要没有主动触发远程引用同步操作，这份本地副本就会一直保留，即便服务端已经把对应分支删除，本地查询时依然会从旧副本里读取到这些分支条目。
• 对应你遇到的场景：Azure网页端的分支列表是直接读取服务端的实时分支数据，没有本地缓存的中间环节，所以显示的状态是符合预期的；而本地运行git branch -r时读取的是本地留存的旧快照，自然会展示已经被服务端删除的dev、dev2分支。

• 执行远程缓存清理命令：git remote prune origin
  这个命令会和远程仓库做实时交互，逐一对账本地存的远程分支快照和服务端的实际分支列表，把服务端已经不存在的本地缓存分支条目彻底移除。
• 命令执行完成后，再次运行git branch -r查看远程分支列表，已经被PR流程删除的dev、dev2分支就会从结果中消失。
• 补充说明：Azure PR流程中勾选删除源分支的操作，作用范围仅覆盖服务端的仓库资源，不会自动帮所有协作开发者清理各自本地存储的远程分支缓存，这一行为属于Git本身的本地缓存机制，并非Azure PR流程的逻辑漏洞。

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