适合长期特性开发与并行热修复的Git工作流名称及替代方案咨询

我们当前基于两个分支开展工作：develop
特性分支均从develop创建，变更完成后将特性分支合并回develop。
目前我们正在开发名为u1的重大更新，预计3个月内无法完成。在此期间，我们需要为当前版本提供与u1无关的其他功能和热修复。
为实现该需求，我提出如下方案：
从develop新建一个仅包含u1相关特性的分支，所有u1相关功能都提交到u1分支；继续从develop创建热修复等其他特性分支，将热修复合并到develop。待u1功能完备后，将u1分支合并到已经包含前述热修复的develop分支。请问该Git策略的官方名称是什么？是否有其他可替代的Git工作流管理方案？

对应Git策略的官方名称 #

你描述的方案属于 长期特性分支（Long-lived Feature Branch） 实践，是通用特性分支工作流的延伸场景。如果你的团队原本就遵循经典Git Flow规范，这也属于Git Flow框架下大型特性独立开发的标准落地方式。

可替代的Git工作流管理方案 #

• Git Flow：全流程标准化的分支管理方案，预设main（生产分支）、develop（开发集成分支）、feature/*（特性分支）、hotfix/*（热修复分支）、release/*（预发布分支）五类固定角色分支，分支流转规则明确，非常适合有固定发版周期、需要同时维护多个线上版本的团队，完全匹配你当前并行开发大版本、迭代日常功能/修复bug的需求。
• GitHub Flow：轻量极简的工作流，所有变更都从主干分支拉取，开发完成后提PR验证合并，合并后立即发布。针对你提到的长周期u1开发场景，可以配合特性开关（Feature Flag）使用，未完成的u1功能默认对外隐藏，开发过程中代码可以正常合并到主干，不需要单独维护长期分支，能避免长期分支合并时的大量冲突问题。
• GitLab Flow：介于Git Flow和GitHub Flow之间的方案，在主干分支之外按部署环境设置对应分支（如预发分支、生产分支），合并到主干的代码经过验证后再向上游环境分支合并，既保留了轻量特性，也能满足多环境发布的管控需求。
• 主干开发（Trunk-based Development）：迭代效率最高的开发模式，所有开发者的代码每日合并到主干分支，未完成的大功能通过特性开关隐藏，完全不需要维护长期特性分支，能彻底规避长期分支合并带来的冲突、代码不同步问题，适合自动化测试覆盖度高、迭代节奏快的团队。

内容的提问来源于stack exchange，提问作者blue-sky