双周发版的 SaaS 产品
使用场景: 按双周迭代交付的 Web 应用研发团队
main：仅含生产版本，每次发版打 Tag
develop：所有 feature 审核后合并到此
feature/user-auth、feature/dashboard：短周期分支，发版前合并完毕
release/2.3：从 develop 切出后仅允许 Bug 修复，合并到 main 后打 v2.3 标签
hotfix/2.3.1：紧急补丁，合并到 main 和 develop
这样组织的原因: release 分支充当代码冻结门控，切出后不再合入新功能，保障发版稳定性，同时 develop 上的迭代工作可以并行继续。
需要应用商店审核的移动应用
使用场景: iOS/Android 开发者管理提审流水线
main：仅在商店审核通过后更新
develop：持续集成目标分支
feature/*：每个任务一个分支，通过 PR 合并
release/3.0：包含商店元数据和构建配置变更
hotfix/3.0.1：紧急崩溃修复，走加急审核通道
这样组织的原因: 应用商店审核周期让 release 分支尤为重要——它将提审队列与日常功能开发解耦，让 QA 有稳定的产物可以测试。
在校生初学 Git Flow
使用场景: 计算机专业学生或训练营学员练习分支工作流
main：仅一个初始提交
develop：所有作业集成到这里
feature/add-login：第一个 feature 分支，经同学 Code Review 后合并
release/v0.1：期中作业提交版本标签
hotfix/fix-typo：模拟紧急修复流程
这样组织的原因: 在小项目上完整走一遍 Git Flow 流程——即使改动很小——能建立肌肉记忆，上手真实项目时不会手忙脚乱。
