直接回答
GitFlow 是多分支的发布型工作流：长期维护 main（生产）和 develop（集成分支），功能开 feature 分支、发布开 release 分支、紧急修复开 hotfix 分支，适合有明确版本节奏、需同时维护多个发布版本的场景。GitHub Flow 是极简的持续部署流：只有 main 一条长期分支，工作在短期 feature 分支完成，经 Pull Request 评审后合并即部署，适合能快速上线的 Web 服务。
展开解析
核心差异在复杂度与发布模型的匹配。GitFlow 分支多、规则重，换来版本控制力：release 分支可冻结做回归，hotfix 从 main 切出再回填，支持"线上跑 2.x、开发在做 3.0"的并行维护，适合客户端软件、SDK 等无法强迫用户升级的交付物；代价是合并链路长、两主分支长期偏离。GitHub Flow 押注"主干永远可发布"：合并即上线，靠 PR 评审、CI 门禁和特性开关控制风险，历史简单；但前提是你能快速部署且不维护旧版本——APP 商店审核、私有化部署场景就不适用。追问：feature flag 如何替代长生命周期分支、GitHub Flow 下 hotfix 怎么处理（普通 PR 加急即可）。