Azure DevOps使用Git Squash-Commit合并PR时出现大量虚假文件更新问题

核心根因 #

Squash 合并的本质是完全丢弃原功能分支的所有提交历史，在目标分支（开发分支）生成一个和原提交没有任何父子关联关系的全新压缩提交。当你第一次将功能分支Squash合并到开发分支后，Git无法识别原功能分支的提交已经被整合到了开发分支中。
如果后续你没有将开发分支的最新代码同步回功能分支，再次提交PR时，Git会将功能分支上所有历史提交对应的变更与开发分支当前内容做全量比对，就会出现你遇到的「数千条已提交文件被识别为新变更」的虚假更新问题。

常见触发错误的操作场景 #

• 功能分支Squash合并到开发分支后，没有删除旧功能分支，后续直接在旧功能分支上继续开发新需求，再次提交PR
• 多人员共用同一个功能分支协作，有人将分支Squash合并到开发分支后，其他协作人员没有同步最新的开发分支代码到本地，继续在旧的分支记录上提交代码
• 长期迭代的公共特性分支，持续使用Squash方式向开发分支合并代码

临时修复当前问题的方法 #

1. 先备份本地功能分支代码，避免操作失误丢失内容
2. 执行git rebase origin/[你的开发分支名称]，将功能分支的提交变基到最新的开发分支之上，解决过程中出现的冲突后推送到远程，PR的变更列表就会自动过滤掉已经合并过的内容
3. 如果对变基操作不熟悉，也可以基于最新的开发分支新建功能分支，将本次需要提交的变更cherry-pick到新分支后提交新PR即可

长期规避方案 #

• 所有短期功能分支Squash合并到开发分支后，必须立刻删除该功能分支，后续新需求必须基于最新的开发分支新建分支开发
• 长期存在的公共协作分支不要使用Squash合并，改用普通合并提交或者变基合并
• 每次提交PR前，先同步远程开发分支的最新代码到本地功能分支，确认变更范围符合预期后再提交

关于重复提交的影响 #

即使你直接合并这些虚假变更，Git最终会比对到文件内容和开发分支现有内容完全一致，不会真的覆盖现有文件，但会导致仓库提交历史完全混乱，后续版本回滚、问题排查的效率会受到严重影响，不建议直接合并。

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