看板、生产支持与环境场景下Git合并策略优化问询

当前问题根源 #

你当前的流程中，用cherry-pick挑选部分特性从develop合并到master，同时master的热修复或上线调整未及时同步回develop，加上未上线特性长期滞留在develop中，导致两个分支出现双向提交差异，最终引发频繁复杂的合并冲突。核心问题是分支流转的非对称性和未上线特性的长期滞留。

Feature Branch模式相关疑问解答 #

1. CICD分支如何设置 #

Feature Branch模式下，建议保留以下分支角色：

• feature/xxx：单个特性的开发分支，从develop拉取，开发完成后提PR到develop
• develop：集成测试分支，作为CI的核心触发分支，合并feature后自动部署到集成测试环境
• release/xxx：上线准备分支，从develop拉取，仅用于上线前的bug修复和配置调整，测试通过后合并到master和develop
• master：生产分支，仅接收release分支的合并，合并后打版本tag，触发生产部署

CI层面：每个feature分支提交时自动执行编译、单元测试、代码扫描；PR到develop时触发集成测试；release分支部署到预发布环境；master分支触发生产部署。

2. 是否需要为每个特性配置独立开发环境 #

不是必须，但推荐根据特性复杂度和团队规模选择：

• 对于依赖少、逻辑简单的小特性：可以共用集成环境，合并到develop后统一测试
• 对于复杂特性、跨模块改动或需要独立验证的功能：用动态临时环境（结合Docker+K8s或云平台的按需部署能力），每个PR自动创建临时环境，测试完成后销毁。ASP.NET可以通过Dockerfile快速打包镜像，配合CI工具（比如GitHub Actions、GitLab CI）实现一键部署临时环境。

3. 如何追踪特性间的依赖关系 #

• 代码提交层面：提交信息中添加依赖标记，比如feat: 用户管理模块 #123 DependsOn: #456，关联依赖特性的PR编号
• 项目管理层面：在Jira/Trello等工具的特性卡片中明确标记依赖关系，确保开发顺序清晰
• 代码架构层面：通过ASP.NET的模块化设计（比如拆分独立类库、微服务）降低特性间耦合，减少跨特性依赖的场景

其他降低代码流转痛点的方案 #

1. 结合Feature Flag（特性开关）的Git Flow #

将所有特性合并到develop，通过特性开关控制是否启用，避免未上线特性长期滞留develop。上线时从develop拉取release分支，仅打开需要上线的特性开关，测试通过后合并到master和develop。ASP.NET可以直接使用官方的Microsoft.FeatureManagement库，通过配置文件或远程配置中心（比如App Configuration）快速开关特性。

这种方式能彻底消除develop和master的双向差异，因为master始终是develop的一个稳定快照，仅特性开关配置不同。

2. Trunk-Based Development（主干开发） #

采用master作为主干分支，所有开发都基于短生命周期的feature分支（通常1-3天合并），合并前必须通过CI测试，上线用特性开关控制未完成的功能。这种模式下分支差异极小，冲突概率低，适合敏捷迭代的团队。ASP.NET配合自动化测试（xUnit、NUnit）和特性开关，能快速落地该模式。

3. 终止cherry-pick，改用对称分支流转 #

停止从develop cherry-pick到master，改为：

• 未上线的特性留在feature分支，不合并到develop，直到确定上线
• master的热修复或上线调整，及时合并回develop
• 上线时从develop拉取release分支，测试后合并到master和develop

这种方式能保证develop和master的差异仅为已上线特性和同步的热修复，避免双向提交混乱。

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