如何在现有部署流程中处理Git分支冲突问题

背景 #

我们的部署流程：

• 开发人员从main分支创建feature分支，完成变更后通过Pull Request（PR）合并至QA、UAT等预发布分支
• UAT验证通过后，该分支上线至生产环境
• 使用Github Actions：PR发起后先执行部署验证，验证通过进入评审环节，分支合并至QA/UAT时触发部署

当前核心问题：向QA/UAT分支提交PR时出现分支冲突，若直接在PR中解决冲突，会导致QA/UAT分支的所有其他变更被合并到feature分支，这不符合我们的需求。

目前使用的两种非推荐方案：

1. 直接修改目标分支（如UAT）的冲突文件来消除PR冲突
2. 删除QA/UAT分支，从main/master分支重新创建以清除冲突

推荐解决方案：在feature分支上基于目标分支执行rebase #

这种方式会将feature分支的所有提交，基于最新的QA/UAT分支代码重新应用，既能解决冲突，又不会将QA/UAT分支的变更引入到feature分支中，同时保持feature分支的提交历史整洁。

操作步骤（以合并到UAT分支为例） #

1. 拉取最新的UAT分支代码：

   git checkout uat
   git pull origin uat
   

2. 切换回你的feature分支：

   git checkout feature/your-feature-name
   

3. 执行rebase操作，将feature分支基于最新的UAT分支重放提交：

   git rebase uat
   

4. 当Git提示冲突时，打开冲突文件手动解决代码冲突
5. 冲突解决后，将修改的文件加入暂存区，继续rebase：

   git add <已解决冲突的文件名>
   git rebase --continue
   

6. 若中途需要放弃rebase，执行：

   git rebase --abort
   

7. 由于rebase修改了提交历史，需要强制推送更新后的feature分支到远程仓库（使用--force-with-lease更安全，避免覆盖他人提交）：

   git push origin feature/your-feature-name --force-with-lease
   

方案优势对比 #

• 对比方案1：直接修改预发布分支会破坏其稳定性，且容易引发更多连锁冲突，不符合预发布分支的代码管控要求
• 对比方案2：删除重建预发布分支会丢失已验证的所有变更，风险极高，完全不可取

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