一：前言
在现代 SaaS 项目研发流程中，多需求并行开发、多分支同时提交 MR 已是常态。为保证迭代效率，团队通常会采用多分支并行开发模式，A、B、C、D 等多个功能分支同时向同一目标分支 F 发起合并请求，也是日常协作中极为常见的场景。
然而这种协作模式也伴随着典型问题：当 C、D 分支率先完成 MR 审核并合并至 F 分支后，后续合并的 A、B 分支往往会因代码重叠、文件修改冲突而无法直接合并。这类冲突并非代码错误，而是多人协作下的正常产物。
如何在不污染现有分支、不影响已合并功能的前提下，安全、规范、优雅地解决冲突？请接着往下看 ~
二：方案探讨
简化场景说明
- 发布分支：F
- 功能分支：A
- 功能分支：B
A、B 两个功能分支均需发布上线。当前 A 分支已成功合并至 F 分支，B 分支在合并到 F 分支时出现代码冲突，此时应该如何处理呢。
方案对比
方案一：在 B 分支直接合并 F 分支
操作流程：
- 在 B 分支上合并 F 分支
- 解决代码冲突
- 将 B 分支合并回 F 分支
存在问题：
-
分支污染：B 分支会包含 A 分支代码，功能分支不再纯净
-
风险较高：若 A 分支临时取消发布，B 分支需回退操作，步骤繁琐且易出错
方案二：基于 B 分支新建副本分支合并（推荐）
操作思路：不污染原功能分支，通过副本分支处理冲突，保证 B 分支始终只包含自身功能代码，便于后续灵活调整。
操作流程：
1. 基于 B 分支上 创建 B_copy分支
2. 使用B_copy 分支，合并最新的 F 分支，并解决冲突
3. 针对 B_copy 分支新建 MR，目标分支选择 F 分支，将 B_copy 分支合并至 F 分支，完成 B 分支功能的上线
4. B 分支保持独立纯净，仍可用于后续功能迭代
操作流程图：
方案优势
-
分支纯净：原 B 分支不受任何影响，仅保留自身功能代码
-
灵活可控：若 A 分支需临时取消发布，仅需将 F 分支回退至合并A之前的版本，再直接合并原 B 分支即可，无降低操作风险
-
后续管理：B功能分支如果后续还有补充功能，直接使用B分支合并进入F分支就行，不用再次解决冲突，解决冲突记录已保留（在B_copy分支上面解决）
各位小伙伴赶紧去试试吧 ~
