Master与Feature并行开发场景下的最优Git分支策略是什么？
2026-10-2
适配该场景的分支管理方案
方案一：保留现有rebase工作流，解决重复冲突问题
你遇到的重复处理同个冲突的问题，是rebase逐提交重放特性的典型表现，可通过开启Git内置的rerere（重用冲突解决记录）功能直接解决：
- 开启命令：
git config --global rerere.enabled true - 开启后Git会自动记录你每一次手动解决的冲突内容，后续rebase、合并时遇到完全相同的冲突块，会自动应用你之前的解决结果，不需要重复手动处理，完美适配长期rebase的工作流。
- 适用场景：F分支为单人开发、不需要多人协作的特性分支。
方案二：调整为合并式同步，适配多人协作场景
如果F分支是多人协作开发的分支，rebase会修改提交历史导致其他协作者拉取代码出现问题，可将每日rebase改为每日将M分支合并到F分支：
- 合并是一次性对比两个分支的最新提交差异，所有冲突仅需要解决一次，不会出现逐提交重复处理的问题
- 合并不会修改F分支的已有提交历史，不影响多人协作拉取、推送代码
- 测试环境依然部署F分支即可，生产发布时直接发布M分支，完全满足发布规则要求。
方案三：新增独立测试集成分支（最稳妥的长期方案）
如果不想日常同步操作污染M、F两个分支的原生历史，可新增专门的test-integration测试集成分支，流程如下：
- 首次创建：从最新的M分支检出集成分支：
git checkout -b test-integration origin/M - 每日部署测试前更新集成分支：
- 切换到集成分支：
git checkout test-integration - 合并最新的M分支代码：
git pull origin M - 合并最新的F分支代码：
git pull origin F - 解决所有冲突后提交，直接部署该集成分支即可
- 切换到集成分支：
- 生产发布时完全不需要处理该集成分支，直接发布M分支内容即可
- 优势：完全隔离测试集成操作和生产分支、特性分支的历史，冲突仅需要在集成分支解决一次，后续如果有多个特性分支需要同时进入测试，只需将对应分支合并到集成分支即可，扩展性极强。
内容的提问来源于stack exchange，提问作者Haoest
相关产品推荐
相关产品推荐
