前端工程化 - 市面上主流的git工作流

目前市面上主流的工作流

Git Flow

📌 核心理念

1. 明确角色的分支：每条分支都有固定职责
2. 稳定 main：main 永远是可发布的生产版本
3. 开发在 develop：feature 先合入 develop，再发布
4. 发布有 release 分支
5. 紧急修复用 hotfix 分支

🗂 分支结构

main             ← 生产环境分支
develop          ← 开发主干
feature/*        ← 功能分支（短期）
release/*        ← 准备发布的分支
hotfix/*         ← 紧急修复分支

• main：
  • 永远保持可部署状态
• develop：
  • 聚合所有 feature，准备进入 release
• feature/：
  • 单个功能或任务分支，短期存在
• release/：
  • 发布分支，做最终测试和 Bug 修复
• hotfix/：
  • 线上紧急修复

⚙️具体操作流程

• 初始化

  # 初始化 Git Flow 分支结构
  git checkout -b develop main
  

• 创建功能分支（feature）

  # 从 develop 拉取
  git checkout develop
  git checkout -b feature/login
  
  # 开发、提交
  git add .
  git commit -m "feat: login page"
  
  # 完成后合并回 develop
  git checkout develop
  git merge --no-ff feature/login
  
  # 删除功能分支
  git branch -d feature/login
  

  💡特点：

  • 每个 feature 分支独立
  • 生命周期短
  • 功能完成即合并回 develop

• 创建发布分支（release）

  当 develop 达到一个可发布状态（比如版本 1.2）

  git checkout develop
  git checkout -b release/1.2
  
  # 可以做最后的 Bug 修复、文档修改
  git add .
  git commit -m "fix: release bug"
  
  # 完成后，合并到 main 和 develop
  git checkout main
  git merge --no-ff release/1.2
  git tag -a 1.2 -m "Release 1.2"
  
  git checkout develop
  git merge --no-ff release/1.2
  
  # 删除 release 分支
  git branch -d release/1.2
  

  特点：

  • release 分支存在时间较短
  • 用于最终测试、QA
  • 保证 main 的稳定性

• 紧急修复（hotfix）

  当生产环境发现 Bug，需要快速修复

  git checkout main
  git checkout -b hotfix/1.2.1
  
  # 修复 Bug
  git add .
  git commit -m "fix: critical bug"
  
  # 合并回 main 和 develop
  git checkout main
  git merge --no-ff hotfix/1.2.1
  git tag -a 1.2.1 -m "Hotfix 1.2.1"
  
  git checkout develop
  git merge --no-ff hotfix/1.2.1
  
  # 删除 hotfix 分支
  git branch -d hotfix/1.2.1
  

  💡 特点：

  • 直接从 main 拉分支
  • 修复完立即发布
  • 不影响 develop 长期开发

• 周期与节奏

  • 功能开发周期：短期（几天到一周）
  • Release 测试周期：几天
  • Hotfix：随时出现

  所以 Git Flow 的节奏是：

  多 feature → develop → release → main → tag → 部署

优缺点总结

• 优点：
  • 分支职责明确
  • main 保持稳定，易于发布
  • 支持并行开发
  • 企业级项目成熟稳定
• 缺点：
  • 分支多，操作复杂
  • 冲突可能累积
  • 对 CI/CD 自动化要求高
  • 不适合持续部署 / 高频迭代

GitHub Flow

📌 核心理念

• 极简分支模型：
  • 只有 main（或 master）和短期 feature 分支
• 持续部署：
  • 每次合并到 main 都可以部署
• Pull Request 驱动：
  • 通过 PR 审核、测试、合并
• 短生命周期分支：
  • feature 分支生命周期一般只几天

💡 核心思想：

主干就是唯一可发布版本，所有开发都靠短分支 + 自动化测试保证稳定性。

🗂 分支结构

main         ← 生产环境分支
feature/*    ← 功能分支（短期）

特点：

• 没有 develop 分支
• 没有 release 分支
• 没有 hotfix 分支（hotfix 直接在 feature 分支上修复，然后合并 main）

⚙️ 具体操作流程

• 创建功能分支

  git checkout main
  git pull origin main
  git checkout -b feature/login
  

  • 你从 main 拉分支，不影响生产
  • 分支命名通常用 feature/xxx 或 bugfix/xxx

• 开发、提交

  # 修改代码
  git add .
  git commit -m "feat: add login page"
  git push origin feature/login
  

  • 每次开发小步提交
  • 推送远程后可以打开 PR（Pull Request）进行代码审核

• Pull Request 审核 & 测试

  • 打开 PR（ web 上操作）
  • CI 自动跑测试
  • 其他开发者 review 代码
  • 审核通过后合并到 main

  💡 特点：PR 是唯一控制质量的环节

• 合并到 main & 部署

  git checkout main
  git pull origin main
  git merge --no-ff feature/login
  git push origin main
  

  • 代码合并到 main 就可直接部署
  • 由于 feature 分支短生命周期，冲突少
  • 如果发现问题，可立即在 main 上创建新的修复分支

• 删除 feature 分支

  git branch -d feature/login
  git push origin --delete feature/login
  

  • 保持仓库整洁
  • 短期分支生命周期结束即删除

✅ 特点总结

• 优点：
  • 简单，学习成本低
  • 分支少，管理轻量
  • 支持持续部署 / 持续交付
  • 冲突少，短生命周期
• 缺点：
  • 对 CI/CD 自动化要求高
  • main 必须随时保持可部署状态
  • 不适合长期发布版本控制（没有 release 分支）
  • 对多人同时开发大型功能可能略吃力

🔹 对比 Git Flow

维度	Git Flow	GitHub Flow
分支数量	多	少
发布节奏	周期性/版本	随时/持续
开发分支	develop + feature	feature 直接从 main
hotfix	专门分支	直接 feature/bugfix
学习成本	中高	低
企业级适合度	高	中

GitLab Flow

📌 核心理念

• 结合 issue、环境、CI/CD
• 简化分支，同时兼顾发布稳定性
• 灵活的分支策略：既可以像 GitHub Flow 极简，也可以像 Git Flow 支持 release
• 环境驱动分支：例如 production、staging、pre-production

核心思想：分支策略和部署环境绑定，而不是只用版本号管理分支

🗂 分支结构（主要几种变体）

• 基础 GitHub Flow 式

  main (production)
  feature/*
  

  • 适合持续部署
  • main 是生产环境
  • feature 分支短生命周期

• 环境分支式（推荐企业模式）

  main / production        ← 生产环境
  pre-production / staging ← 预发布环境
  develop / integration    ← 开发集成环境
  feature/*                ← 功能分支
  

  • 代码从 feature → develop → staging → production
  • 分支和环境绑定，部署路径清晰
  • 适合多环境测试流程

• Release 分支式（结合 Git Flow）

  main
  develop
  feature/*
  release/*
  

  • 和 Git Flow 类似
  • 适合需要版本管理的企业
  • 在 GitLab 上配合 CI/CD 自动部署

⚙️ 具体操作流程（环境分支式）

• 创建功能分支

  git checkout develop
  git checkout -b feature/login
  # 开发完成
  git add .
  git commit -m "feat: login page"
  git push origin feature/login
  

  • 从 develop（集成环境）拉分支
  • 每个 feature 对应一个 issue/任务

• 合并到 develop（集成环境）

  git checkout develop
  git merge --no-ff feature/login
  git push origin develop
  

  • CI 自动跑测试
  • 集成测试通过后，准备发布到预发布环境

• 合并到 staging / pre-production

  git checkout staging
  git merge --no-ff develop
  git push origin staging
  

  • 部署到预发布环境
  • QA 测试
  • 可以打 tag 或 release

• 合并到 production / main

  git checkout main
  git merge --no-ff staging
  git tag -a v1.2 -m "Release 1.2"
  git push origin main --tags
  

  • 生产环境部署
  • 分支和环境一一对应，风险可控

• 紧急修复（hotfix）

  git checkout main
  git checkout -b hotfix/login-fix
  # 修复 Bug
  git add .
  git commit -m "fix: login bug"
  git push origin hotfix/login-fix
  
  # 合并到 main + 其他环境
  git checkout main
  git merge --no-ff hotfix/login-fix
  git checkout develop
  git merge --no-ff hotfix/login-fix
  git checkout staging
  git merge --no-ff hotfix/login-fix
  

  • 可以同时同步到所有环境
  • 保证线上和测试环境一致

✅ 特点总结

优点：

• 分支和部署环境绑定，管理清晰
• 结合 GitLab CI/CD 自动化强
• 支持多环境测试、QA、预发布
• 可以按需使用 release 分支或直接简化为 GitHub Flow

缺点：

• 对分支管理和流程要求高

• 对 CI/CD 不成熟的团队可能操作繁琐

• 仍然有合并冲突风险

• 🔹 对比 Git Flow / GitHub Flow

  维度	Git Flow	GitHub Flow	GitLab Flow
  分支数量	多	少	中
  发布节奏	周期性/版本	随时/持续	可灵活（环境绑定）
  分支角色	feature/release/hotfix	feature	feature + environment (staging/production)
  CI/CD 依赖	可选	强依赖	强依赖
  企业适合度	高	中	高（尤其多环境团队）

GitLab Flow = GitHub Flow + 环境驱动分支 + CI/CD，适合企业多环境发布的现代工作流”

Trunk-Based Development

📌 核心理念

• 主干（trunk / main）是唯一长期分支
• 功能分支极短生命周期（一般 1~2 天）
• 频繁提交到主干（每天多次）
• 通过 feature flags（功能开关）控制功能上线
• CI/CD 自动化保证主干可部署

核心思想：不依赖长期分支，而靠小步快跑 + 自动化测试保证稳定性

🗂 分支结构

main (或 trunk)
feature/* (短期, 一般1~2天)

• 特点：
  • 没有 develop
  • 没有 release 分支
  • 没有长期 feature 分支
  • 所有开发尽量快速合并到 main

⚙️ 具体操作流程

• 创建短期 feature 分支

  git checkout main
  git pull origin main
  git checkout -b feature/login
  

  • 生命周期非常短，一般当天或两天内完成开发
  • 每个 feature 分支通常对应一个小功能或任务

• 小步提交 & 推送

  git add .
  git commit -m "feat: login page"
  git push origin feature/login
  

  • 提交粒度小，确保冲突少
  • 推送后可以触发 CI 测试

• 快速合并回主干

  git checkout main
  git pull origin main
  git merge --no-ff feature/login
  git push origin main
  

  • 一般每天多次合并
  • CI/CD 确保 main 始终可部署

• 使用 Feature Flags 控制上线

  • 通过配置开关控制功能是否对用户可见
  • 这样即使 main 上的功能尚未完成，也不会影响生产环境

• 修复 Bug / Hotfix

  • 直接在 main 上创建极短生命周期的分支
  • 修复完成立即合并
  • 同样依赖 CI/CD 自动化测试

✅ 特点总结

• 优点：
  • 简单，只有一个长期分支
  • 冲突少，快速迭代
  • 支持持续集成、持续部署（CI/CD）
  • 功能通过 feature flag 上线，灵活性高
  • 现代互联网公司首选模式
• 缺点：
  • 对 CI/CD 自动化要求极高
  • 所有开发者必须遵守小步提交原则
  • 不适合缺乏自动化测试的团队
  • 对大型功能可能需要拆分或使用 feature flag

🔹 对比其他工作流

维度	Git Flow	GitHub Flow	GitLab Flow	Trunk-Based
分支数量	多	少	中	极少
发布节奏	周期性	随时	可灵活	持续/高频
分支角色	feature/release/hotfix	feature	feature + environment	feature 极短
冲突风险	中高	低	中	低
企业适合度	传统企业	SaaS 小团队	企业多环境	高频互联网团队
CI/CD 依赖	可选	强	强	必须

Trunk-Based Development = “一个主干 + 短分支 + CI/CD + feature flag”，是现代互联网高频发布团队的标配。

Forking Workflow

📌 核心理念

• 每个贡献者都有自己独立的仓库（fork）
• 所有开发通过 Pull Request（PR）合并到主仓库
• 主仓库保持稳定和可部署
• 强隔离，防止直接修改主仓库

核心思想：每个人在自己的“沙盒”里开发，审核后才合入主仓库

🗂 分支结构

• 每个 fork 仓库：

  main (或者 master) ← 贡献者自己 fork 的仓库
  feature/*          ← 功能分支（短期）
  

• 主仓库：

  main (master)       ← 生产环境
  

• 特点：

  • 主仓库几乎只接受 PR
  • 贡献者本地 / fork 仓库自由操作
  • 适合开源或跨组织协作

⚙️ 具体操作流程

1. Fork 主仓库

   • 在 GitHub / GitLab 上点击 Fork
   • 得到自己账户下独立仓库

2. 克隆到本地

   git clone git@github.com:your-username/project.git
   cd project
   git remote add upstream git@github.com:original-owner/project.git
   

   • origin 指向你的 fork
   • upstream 指向主仓库

3. 创建功能分支

   git checkout main
   git pull origin main
   git checkout -b feature/login
   

   • 分支在 fork 仓库内
   • 生命周期短

4. 开发 & 提交

   git add .
   git commit -m "feat: add login"
   git push origin feature/login
   

   • 提交到自己的 fork 仓库
   • 不影响主仓库

5. 创建 Pull Request

   • 打开 GitHub / GitLab
   • 从 your-username:feature/login 提交到 upstream:main
   • 代码审核 + CI 测试

6. 审核 & 合并

   • 维护者 review PR
   • 通过后 merge 到主仓库 main

   💡 特色：

   • 每次贡献都通过 PR
   • 主仓库保持稳定
   • 支持多人分布式开发

7. 同步主仓库更新

   git fetch upstream
   git checkout main
   git merge upstream/main
   git push origin main
   

   • 保持 fork 仓库最新
   • 避免冲突

✅ 特点总结

• 优点：
  • 强隔离，不破坏主仓库
  • 非常适合开源项目和分布式团队
  • 每次改动都可审查，保证质量
  • 可管理多贡献者，多组织协作
• 缺点：
  • PR 频繁，流程多
  • 对新手学习成本稍高
  • 主仓库更新慢或合并冲突需要手动解决

🔹 对比其他工作流

维度	Git Flow	GitHub Flow	GitLab Flow	Trunk-Based	Forking
分支数量	多	少	中	极少	每人 fork 都有独立分支
发布节奏	周期性	随时	可灵活	持续/高频	依赖主仓库 merge
开发隔离	中	低	中	低	高
审核机制	可选	PR	PR	自动测试	PR 必须
企业适合度	传统企业	SaaS 小团队	企业多环境	高频互联网团队	开源/跨组织

Forking Workflow = “每个人独立 fork 仓库 + PR 驱动主仓库”，是开源项目协作的标准模式。 "”

Release Train Model

📌 核心理念

• 固定时间发布（每周、每两周、每月）
• 所有完成的功能赶上“列车”就上线，不赶上就下次发布
• 功能分支可以多，但最终必须按发布窗口合并
• 保证节奏稳定，减少临时发布压力

核心思想：发布是按时间，而不是按功能完成度来决定

🗂 分支结构

main             ← 生产分支（列车终点）
feature/*        ← 功能分支（短期）
release/*        ← 当前发布列车分支

• 特点：
  • main 永远是稳定的生产版本
  • feature 分支开发功能
  • release 分支对应“本期列车”，收集本期功能

⚙️ 具体操作流程

• 创建功能分支

  git checkout main
  git checkout -b feature/login
  # 开发完成
  git add .
  git commit -m "feat: login page"
  git push origin feature/login
  

  • 每个功能短期开发
  • 可以并行多个功能分支

• 月初 / 本期列车启动

  git checkout main
  git checkout -b release/2026-02
  

  • 创建 release 分支，对应本期列车（例如 2026 年 2 月）
  • 本期列车收集已经完成的功能分支

• 合并功能分支到 release

  git checkout release/2026-02
  git merge --no-ff feature/login
  git merge --no-ff feature/payment
  git merge --no-ff feature/profile
  

  • 所有准备上线的功能分支汇总到 release
  • QA / 测试在 release 分支上进行

• Release 分支完成后合并到 main

  git checkout main
  git merge --no-ff release/2026-02
  git tag -a v1.5 -m "Release 1.5"
  git push origin main --tags
  

  • 部署上线
  • 下个月的新列车从 main 切新的 release 分支

• 未赶上本次列车的功能

  • 保留在 feature 分支
  • 下一期列车再合并

• 紧急修复（hotfix）

  • 可以直接从 main 拉 hotfix 分支
  • 修复完成立即合并回 main 和当前 release 分支（如果还在 QA）

✅ 特点总结

• 优点：
  • 发布节奏固定，可预测
  • 多功能分支并行开发，减少临时上线压力
  • QA / 测试时间可规划
  • 企业适合度高，管理易沟通
• 缺点：
  • 功能未完成不能上线，可能滞后
  • 冲突可能在 release 汇总时集中爆发
  • 不适合持续交付 / 高频部署

🔹 对比其他工作流

维度	Git Flow	GitHub Flow	GitLab Flow	Trunk-Based	Forking	Release Train
分支数量	多	少	中	极少	每人 fork	中
发布节奏	周期性/版本	随时/持续	可灵活	高频	依赖主仓库 merge	定期列车
功能是否必须完成	是	否	可选	否	否	是（赶上列车）
冲突风险	中高	低	中	低	中	中高
企业适合度	高	中	高	高频互联网	开源	企业周期性发布

Release Train Model = “固定时间发车，所有完成功能赶上列车就上线”，适合企业周期性发布、多功能并行的场景。

Environment-Based Workflow

📌 核心理念

• 分支和部署环境一一对应
• 代码从开发环境逐步流向生产环境
• 每个环境可以独立测试和部署
• 多环境 QA / UAT / 预生产可并行进行

核心思想：环境驱动分支，发布风险可控

🗂 分支结构（典型企业模式）

main / production        ← 生产环境
staging / pre-production ← 预发布环境
develop / integration    ← 开发集成环境
feature/*                ← 功能分支

• 特点：
  • feature/：短期开发
  • develop / integration：功能汇总和集成测试
  • staging / pre-production：预发布环境 QA 测试

⚙️ 具体操作流程

• 创建功能分支

  git checkout develop
  git checkout -b feature/login
  # 开发完成
  git add .
  git commit -m "feat: login page"
  git push origin feature/login
  

  • 从 develop 拉分支
  • 生命周期短
  • 每个 feature 对应一个任务或 issue

• 合并到开发/集成环境

  git checkout develop
  git merge --no-ff feature/login
  git push origin develop
  

  • 集成所有 feature 分支
  • CI/CD 自动构建
  • 开发环境测试

• 合并到预发布环境（staging）

  git checkout staging
  git merge --no-ff develop
  git push origin staging
  

  • 部署到 staging
  • QA 测试、性能验证、UAT
  • 可以打临时 tag 或 release candidate

• 合并到生产环境（main / production）

  git checkout main
  git merge --no-ff staging
  git tag -a v1.5 -m "Release 1.5"
  git push origin main --tags
  

  • 部署生产环境
  • 分支和环境一一对应，风险可控

• 紧急修复（hotfix）

  git checkout main
  git checkout -b hotfix/login-fix
  # 修复 bug
  git add .
  git commit -m "fix: login bug"
  git push origin hotfix/login-fix
  
  # 同步到所有环境
  git checkout main
  git merge --no-ff hotfix/login-fix
  git checkout staging
  git merge --no-ff hotfix/login-fix
  git checkout develop
  git merge --no-ff hotfix/login-fix
  

  • 修复可同步到每个环境
  • 保证生产和测试环境一致性

✅ 特点总结

• 优点：
  • 分支与环境绑定，发布流程清晰
  • 多阶段测试，风险可控
  • 支持企业 QA 流程
  • 可和 GitLab CI/CD 完美结合
• 缺点：
  • 分支和环境多，管理复杂
  • 冲突可能集中在合并到 staging / main 时
  • 对自动化测试和 CI/CD 依赖较高
  • 不适合高频发布的小团队

🔹 对比其他工作流

维度	Git Flow	GitHub Flow	GitLab Flow	Trunk-Based	Forking	Release Train	Environment-Based
分支数量	多	少	中	极少	每人 fork	中	多
发布节奏	周期性/版本	随时/持续	灵活	高频	PR 驱动	定期列车	阶段性/环境驱动
功能是否必须完成	是	否	可选	否	否	是	否，可阶段测试
冲突风险	中高	低	中	低	中	中高	中高
企业适合度	高	中	高	高频互联网	开源	企业周期性发布	大型企业多环境

Environment-Based Workflow = “分支与环境一一对应，代码从开发 → staging → production 流动”，适合企业多环境、多阶段测试的发布模式。

Monorepo + Trunk 模式

这是 Google、Meta、Microsoft 等大型科技公司在多项目、大型团队中常用的工作流。它结合了 单仓库管理 + 主干开发 的优势，适合超大规模协作。

📌 核心理念

• Monorepo：多个项目/模块放在一个仓库里
• Trunk-Based Development：只有一个主干（trunk / main），功能分支极短
• 小步快跑 + CI/CD 自动化
• 功能通过 feature flag 或配置控制上线
• 全局一致性：版本依赖、代码风格、工具链统一

核心思想：单仓库统一管理 + 主干开发 + 自动化保证稳定性

🗂 分支结构

main (或 trunk)          ← 所有项目的唯一长期分支
feature/*                ← 短期功能分支（一般几小时到 1-2 天）

• 特点：
  • 没有 develop
  • 没有 release 分支
  • 单仓库内包含多个子项目 / 模块
  • 所有开发都快速合入 main

⚙️ 具体操作流程

• 创建短期 feature 分支

  git checkout main
  git pull origin main
  git checkout -b feature/login
  

  • 分支生命周期短
  • 小功能或者模块改动

• 小步提交 & 推送

  git add .
  git commit -m "feat: login page"
  git push origin feature/login
  

  • 提交粒度小
  • 每次提交触发 CI 构建

• 快速合并回主干

  git checkout main
  git pull origin main
  git merge --no-ff feature/login
  git push origin main
  

  • 保证 main 随时可部署
  • CI/CD 确保稳定性

• 使用 Feature Flags 控制上线

  • 功能开发完成后先不影响用户
  • 通过配置开关控制是否在生产环境激活

• 处理多项目依赖

  • Monorepo 内模块依赖统一管理
  • 可以在主干上同时修改多个项目
  • CI/CD 会检查全局构建和测试，保证依赖一致

• 紧急修复 / Hotfix

  • 直接在 main 或 trunk 创建短期分支
  • 修复完成立即合并回主干

✅ 特点总结

• 优点：
  • 单仓库统一管理，多项目依赖一致
  • Trunk-Based 开发，高频合并低冲突
  • 支持全局 CI/CD 自动化构建
  • 功能通过 feature flag 上线灵活
  • 大型团队协作效率高
• 缺点：
  • 仓库可能非常大，工具链要求高
  • 对 CI/CD 和自动化测试依赖极高
  • 新手学习成本较高
  • 功能分支管理必须严格，否则容易冲突

🔹 对比其他工作流

维度	Git Flow	GitHub Flow	GitLab Flow	Trunk-Based	Forking	Release Train	Environment-Based	Monorepo + Trunk
分支数量	多	少	中	极少	每人 fork	中	多	极少
发布节奏	周期性	随时	灵活	高频	PR 驱动	定期列车	阶段性	高频主干
功能是否必须完成	是	否	可选	否	否	是（赶上列车）	否	否，feature flag 控制
多项目管理	中	低	中	低	中	中	中	高（单仓库多项目）
企业适合度	高	中	高	高频互联网	开源	企业周期性发布	大型企业多环境	超大型企业

Monorepo + Trunk = “单仓库 + 主干开发 + CI/CD + feature flag”，适合超大规模、多项目、多团队协作的现代科技公司。

各个工作流比较

模型	分支多吗	发布频率	适合企业	现代度
Git Flow	多	低	⭐⭐⭐⭐	⭐⭐
GitHub Flow	少	高	⭐⭐	⭐⭐⭐⭐
GitLab Flow	中	中	⭐⭐⭐⭐	⭐⭐⭐
Trunk-Based	极少	极高	⭐⭐	⭐⭐⭐⭐⭐
Forking	中	不固定	开源	⭐⭐⭐
Release Train	中	定时	⭐⭐⭐⭐	⭐⭐⭐

行业趋势

现在的行业趋势

正在从：

Git Flow → GitHub Flow → Trunk-Based

也就是：

从“分支隔离”走向“主干 + feature flag”