如何通过Pull Request合并分支且不反向引入目标分支变更？

问题根源 #

当前流程的核心矛盾在于：公共testing分支会累积多个开发人员的变更，当后续开发人员的feature分支落后于testing时，必须将testing的所有变更（包括有问题的代码）合并到自己的feature分支，最终导致问题代码随正常变更流入develop分支。

可行解决方案（无需放弃PR与代码扫描） #

• 使用个人临时测试分支隔离变更
  每个开发人员在提交PR到testing前，基于当前最新的testing创建专属临时分支（比如temp-test-dev2），将自己的feature分支合并到这个临时分支后，再发起PR到testing。这样自己的原始feature分支不会被testing的其他变更污染，后续合并到develop时，只会带入自己的代码，不会包含其他人的问题变更。

• 配置PR合并规则，禁止普通合并
  在Git平台的仓库设置中，将testing分支的PR合并方式限定为变基合并（Rebase Merge）或压缩合并（Squash Merge）：

  • 变基合并：会将你的feature分支的提交直接移到testing的最新提交之后，不会生成合并提交，且你的feature分支无需本地合并testing的代码（平台会自动处理）。
  • 压缩合并：会将你feature分支的所有提交压缩成一个单独的提交合并到testing，同样不会让testing的变更反向流入你的feature分支。
    两种方式都能避免feature分支被公共testing的变更污染，同时保留PR的代码扫描环节。

• 及时回滚testing分支的问题变更
  当开发人员1发现自己的变更有问题时，立即通过Git平台的PR撤销功能将自己的合并从testing分支回滚。这样testing分支会恢复到干净状态，后续开发人员2合并时就不会拉取到问题代码。

• 用草稿PR完成代码扫描，延迟合并
  先创建草稿状态的PR到testing分支，完成代码扫描要求后不立即合并。等自己的feature分支测试通过确认无问题，再将草稿PR转为正式状态并合并；如果测试发现问题，直接关闭草稿PR，修改后重新提交，不会污染testing分支。

结论 #

完全不需要放弃PR和代码扫描环节，也不用改用CLI合并，通过调整分支使用方式或Git平台的PR配置，就能解决变更反向污染feature分支的问题。

内容的提问来源于stack exchange，提问作者Fergus O'H