Git 工作流怎么选：Git Flow / GitHub Flow / GitLab Flow / Trunk-based

三句话理解工作流

• 工作流的本质，是用「分支策略」换「集成频率」——分支越多越隔离，但集成越晚、冲突越大。
• 没有最好的工作流，只有匹配团队规模、发布节奏和测试成熟度的那个。
• 大多数团队的真实答案在 GitHub Flow 与 Trunk-based 之间；Git Flow 只在「版本化交付 + 多版本并行维护」时才划得来。

下面先用一张表看差异，再按你的团队情况对号入座。

四种工作流深度对比

Git Flow：分支角色齐全，代价也齐全

五类分支各司其职：

• main：只放已发布版本，每次合并打 tag
• develop：集成开发线，日常提交都汇到这里
• feature/*：从 develop 切出，完成后合回 develop
• release/*：冻结功能、只修 bug，验收后合入 main 并回灌 develop
• hotfix/*：从 main 切出紧急修复，修完同时合回 main 与 develop

仍值得用的场景：交付物是「版本化产品」（桌面端、SDK、私有化部署），且需要同时维护多个已发布版本。

代价：分支多、合并路径长，develop 与 main 长期分叉，「漏合」和冲突是常态。

GitHub Flow：最小可行模型

只有一条长期分支和一条铁律——main 永远可部署：

• 任何改动都从 main 切短命分支 → 提 PR → 评审 + CI 通过 → 合并 → 自动部署
• 合并后立即删除分支，不留「僵尸分支」

git switch -c feat/search main
git push -u origin feat/search      # 开 PR
# 评审通过、CI 绿 → Squash merge → 自动部署
git switch main && git pull

适合：Web 服务、SaaS 等可随时部署的项目。关键约束：CI 是唯一质量闸门，测试不过不许合。

GitLab Flow：在两者之间取平衡

在 GitHub Flow 之上加「环境」或「版本」这一层：

• 环境分支：main → pre-production → production，代码只向前晋升，不回退合并
• 发布分支：为每个维护版本开 1-2-stable，修复先进 main 再 cherry-pick 回发布分支

适合：需要多环境灰度，或既要持续交付又要维护旧版本的团队。

Trunk-based：把集成频率拉到最高

所有人向 main 提交，或只用寿命不足一天的短命分支；未完成功能用 Feature Flag 藏起来：

git switch main && git pull --rebase
# 小步提交，随时可发布；功能开关控制是否对外生效

• 前置条件：自动化测试覆盖足够、CI 反馈在分钟级、有 Feature Flag 治理
• 收益：合并冲突极小、发布节奏自由、回滚靠关开关而不是回滚代码
• 反模式：没有测试就上主干开发 = 把生产当测试环境

怎么选：一张决策清单

• 1~5 人 / 个人项目 → GitHub Flow
• 5~30 人 Web 团队、持续部署 → GitHub Flow，并把分支寿命压到 1~2 天
• 需要多环境灰度 / 同时维护旧版本 → GitLab Flow
• 版本化交付、多版本并行 → Git Flow（或 GitLab Flow 的发布分支变体）
• CI/CD 成熟、追求每天多次发布 → Trunk-based

判断标准只有一个：你的团队能多快把分支合回主干。合不回去的分支策略，再「规范」也是负债。

从 Git Flow 迁到主干开发：渐进四步

1. 先把 CI 补齐：主干必须能自动验证（单测 + 构建 + 冒烟），否则不叫迁移，叫冒险
2. 缩短分支寿命：把 feature 分支从「数周」压到「数天」，先练小步提交
3. 引入 Feature Flag：把未完成功能藏起来，允许半成品进主干
4. 去掉 develop：让 main 成为唯一集成分支，发布改用 tag / 环境晋升

不要一次改完。每步观察一周，出问题就退回上一步——工作流迁移失败，通常是因为测试没跟上就急着删分支。