多特性不同上线时间场景下如何搭建合理的Git工作流？

• 缺乏特性按需上线的隔离能力：所有测试通过的特性无论是否到上线时间，都会提前合并到Development分支，上线时直接全量合并Development到Production，必然连带未计划上线的特性代码进入生产环境，是你遇到的FeatureB v1被意外上线的根因
• 缺少上线前的特性筛选环节：流程没有设计单独挑选待上线特性的步骤，只能全量接受Development分支的所有代码，完全不支持多特性并行开发、分批上线的业务场景
• 分支职责边界模糊：现有设计中Development同时承载了日常集成和待上线代码池的功能，两种职责冲突，无法满足差异化的代码管理需求

分支结构调整 #

• feature/*特性开发分支：所有新特性必须从最新的Production分支切出，从根源上避免分支自带其他未上线特性的代码，开发过程中定期同步Development分支的公共改动
• Development开发集成分支：仅用于日常开发联调，特性开发完成自测通过后即可合并到该分支，不需要等测试全量通过
• release/*发布缓冲分支：每次确定上线清单后，从最新Production分支切出对应版本的release分支，仅合并本次确认要上线、且已通过单特性测试的特性分支
• Production生产分支：仅接收经过release分支全量测试通过的代码，每次合并后必须打对应版本的tag，支持快速回滚
• hotfix/*热修复分支：线上问题直接从Production分支切出，修复完成后同步合并到Production和Development分支，避免修复逻辑遗漏

流程步骤优化 #

1. 特性开发完成自测通过后，合并到Development分支做联调，同时部署到特性测试环境做单功能测试
2. 单特性测试通过后，代码暂存在对应feature/*分支，保持分支代码为可上线状态，定期同步Development的公共改动并回归测试
3. 确定本次上线的特性清单后，从最新Production分支切出release/[版本号]分支，将清单内的特性分支逐一合并到该release分支
4. 对release分支做集成测试、全量回归测试，发现的bug直接在release分支修复，修复内容同步回对应特性分支和Development分支
5. release分支测试通过后，合并到Production分支，打版本tag后部署生产环境
6. 确认线上运行无异常后，删除本次使用的release分支

• 引入特性开关（Feature Flag）：对开发周期长、上线时间不确定的特性加开关控制，即使代码意外进入生产环境，也可以通过开关快速关闭未对外开放的功能，进一步降低上线风险
• 增加合并卡点：所有向Production、release分支的合并操作必须走Pull Request/Merge Request流程，经过至少1位负责人审核、且自动化用例全部通过后才能合并，避免误操作
• 定期清理无效分支：已经上线的特性分支、历史release分支及时删除，降低分支管理成本

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