Azure DevOps下Salesforce发布分支策略导致PR显示历史变更的问题咨询

当前分支策略（基于Azure DevOps） #

• 核心分支：dev（开发）、uat（测试）、master（生产基准）
• 执行流程：
  1. 开发人员从master分支拉取代码，创建Feature分支开展开发
  2. 开发完成后，提交首个PR将Feature分支合并至dev分支
  3. 再创建第二个PR，将Feature分支合并至uat分支
  4. 功能在UAT沙箱环境通过验证
  5. 发布经理从master分支创建Release分支
  6. 通过Cherry-pick或PR方式，将已验证的Feature分支合并至Release分支
  7. 将Release分支部署至生产环境（Prod）
  8. 创建PR将Release分支合并回master分支，更新生产基准

遇到的问题 #

新发布周期启动后，开发人员从master拉取新Feature分支，提交PR至dev或uat时，PR的文件和提交标签页会显示上一版本的所有文件、提交作为新变更，大量无关内容严重干扰开发与评审工作。已知问题源于dev/uat分支未同步master对应的提交ID，导致分支历史分叉。

问题根源与解决方法 #

根源解析 #

每次Release分支合并回master后，dev和uat分支未同步master的最新提交，使得dev/uat与master的提交历史出现分叉。当新Feature分支基于最新master创建后，Git计算PR变更时会将两个分支的所有差异（包括已发布的旧内容）判定为新变更，从而出现无关内容。

具体解决措施 #

1. 发布后立即同步dev/uat与master
   在Release分支合并回master的操作完成后，立刻执行分支同步：

   • 本地操作：

     # 同步dev分支
     git checkout dev
     git pull origin master
     # 解决冲突后推送
     git push origin dev
     
     # 同步uat分支
     git checkout uat
     git pull origin master
     git push origin uat
     

   • 或在Azure DevOps中配置自动PR规则：当master有新提交时，自动创建从master到dev/uat的PR，确保分支同步及时。

2. 提交PR前先同步目标分支到Feature分支
   开发人员在提交PR至dev/uat前，先将目标分支的最新代码合并到自己的Feature分支：

   git checkout feature/你的分支名
   git pull origin dev # 若目标是uat则替换为origin uat
   # 解决冲突后提交并推送
   git commit -m "同步dev分支最新代码"
   git push origin feature/你的分支名
   

   完成后再创建PR，此时PR只会显示Feature分支的实际开发变更。

3. 优化Release到master的合并方式
   将Release分支合并回master时，选择Squash Merge或Rebase Merge（而非默认的No Fast-Forward Merge），减少分支历史的分叉可能性。注意：Squash Merge会将Release分支的所有提交合并为单个提交，若团队需要保留Feature的独立提交历史，可优先选择Rebase Merge。

4. 设置分支保护规则强制同步
   在Azure DevOps的分支设置中，为dev/uat添加保护规则：要求PR的源分支必须与目标分支保持同步（即源分支需包含目标分支的所有最新提交），否则无法创建或合并PR，从流程上强制开发人员同步分支。

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