使用按环境划分分支策略时应如何设置分支流避免合并冲突？

现有流程的核心问题 #

• 缺失常驻分支的反向同步机制：当前只有单向的Develop -> Staging -> Master合并流，即便Staging/Master上的直接提交极少，只要出现过验收回滚、线上hotfix、PR合并生成的独立提交，这些变更永远不会同步回上游的Develop分支，三个常驻分支的提交基线持续分叉，合并时自然会频繁触发冲突。
• PR合并策略不统一：如果不同PR合并到常驻分支时混用squash合并、rebase合并、普通合并三种模式，Git无法追踪跨分支的提交关联，哪怕内容完全一致的提交也会被判定为不同变更，触发误报冲突。
• 无前置冲突处理环节：直接将源分支往目标分支提PR后才发现冲突，没有提前校验解决的步骤。

调整优化方案 #

1. 补充常驻分支反向同步规则 #

每次完成Staging -> Master的上线合并操作后，立刻从Master发起PR合并回Staging，再从Staging发起PR合并回Develop，保证三个常驻分支的提交基线始终对齐，不存在长期分叉的情况。
如果Staging上有验收不通过的功能需要回滚，回滚完成后第一时间将回滚提交同步回Develop，避免后续合并时出现代码差异冲突。

2. 统一全流程PR合并策略 #

所有featureBranch合入Develop的PR统一使用同一种合并策略：

• 选择普通合并（--no-ff）：保留完整提交链，Git跨分支合并时能正确定位共同祖先，大幅降低冲突概率
• 选择squash合并：合并后必须立刻删除源featureBranch，避免重复提交被识别为新变更
  常驻分支之间的合并（Develop -> Staging、Staging -> Master）禁止使用squash或rebase合并，必须使用普通合并模式，保留完整的合并轨迹，保证Git能正确判断变更重合度。

3. 增加预合并校验步骤 #

往Staging/Master提PR前，先在本地把目标分支的最新代码拉取合并到源分支，本地解决完所有冲突后再推送提交PR，不要把冲突留到PR评审阶段处理。

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