敏捷开发场景下Git分支策略合理性及PR冲突解决咨询

1. 当前流程是否合理？ #

不合理，核心问题出在分支流向和集成逻辑的颠倒：

• 分支派生关系为Master→release→Pre-release，但开发流程中却让从release拉出的feature分支先合并到下游的pre-release，再反向合并回上游的release，违背了分支从上游到下游的单向流动原则，会导致分支间版本差异持续扩大，集成复杂度飙升。
• 环境对应逻辑混乱：release分支既标注“仅用于QA环境验证包或不部署”，又定义其部署至staging且最终合并到master上线，职责重叠模糊；pre-release作为UAT验证分支，却成为feature的第一集成点，不符合UAT应验证“准生产版本”的定位。

2. feature向pre-release提交PR冲突严重是否正常？ #

不正常。冲突严重说明分支间的版本同步机制完全失效：

• pre-release和feature分支均从release派生，初始代码基线一致。如果频繁出现大量冲突，大概率是pre-release长期未与release同步更新，或是多个feature分支在pre-release上堆积集成，却未及时将release的最新代码合并到pre-release和feature分支，导致代码差异持续积累。

3. 最优方案（适配敏捷+多环境部署） #

基于敏捷迭代特性，调整为单向流动的分支策略，明确分支与环境的一一对应：

分支定义与环境映射 #

• master：生产分支，仅部署至PROD，仅接收验证通过的release分支合并
• develop：开发集成分支，部署至DEV环境，所有feature分支完成开发后合并至此
• release-<sprint版本>：UAT验证分支，从develop拉取，部署至UAT环境，用于sprint内的功能集成验证

开发与上线流程 #

1. 开发人员从develop拉取feature分支（如feature/US-XXX），完成开发后向develop提交PR，合并后自动部署至DEV环境做基础验证
2. 当sprint内所有feature合并至develop后，从develop拉取release-<sprint版本>分支，部署至UAT环境做全量验证
3. UAT验证通过后，将release-<sprint版本>分支同时合并至master（上线PROD）和develop（同步上线后的修复到开发分支）
4. 若UAT发现问题，直接在release-<sprint版本>分支上修复，验证通过后再同步合并至master和develop

冲突规避机制 #

• 要求开发人员每日将develop的最新代码合并到自己的feature分支，提前解决小冲突
• release分支仅在需要UAT验证时从develop拉取，验证完成后立即合并回develop和master，避免分支长期游离

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