12. GitFlow vs GitHub Flow vs 主干：团队工作流 3 选 1

「Git」系列已发布： 00. 改崩代码不敢回退？Git 版本控制 3 分钟救你狗命 ｜ 01. Git 装完不会配？Windows/macOS/Linux 三端配置一次到位 ｜ 02. Git 配置总踩坑？全局/仓库/SSH 密钥一次搞懂 ｜ 03. add/commit/push 别再死记：Git 工作流核心概念实操 ｜ 04. Git 分支管理：5 步彻底搞懂 branch 与 merge ｜ 05. clone/fetch/pull/push 分不清？Git 远程协作实战 ｜ 06. 给版本打上永久印记：Git 标签管理与发布实战 ｜ 07. 切分支怕丢改动？Git stash 暂存恢复保护现场 ｜ 08. rebase 不是 merge 的替代品：Git 故事线重构进阶 ｜ 09. Git 日志与调试：log/blame/diff 让历史无所遁形 ｜ 10. 提交代码自动检查：Git Hooks 实战，质量不再靠人工 ｜ 11. 多仓库依赖怎么管？Git 子模块统一版本一键更新 ｜ 12. GitFlow vs GitHub Flow vs 主干：团队工作流 3 选 1（本文） ｜ 13. 仓库越来越大？Git LFS 让图片视频不再撑爆仓库

三种主流工作流没有绝对优劣，只有合不合适。本文对比各自适用团队规模与发布节奏，帮你选对那一个，别再抄大厂作业。

阅读本文前，请确保已掌握 Git 分支管理（第 04 篇）和远程协作（第 05 篇）。本文不涉及具体操作，重在理解各工作流的设计哲学和适用场景。

一、为什么需要 Git 工作流

Git 本身提供了强大的分支和合并能力，但没有规定"应该如何使用"。没有统一的规范，团队会面临以下问题：

• 分支命名混乱（my-feature、test-branch、fix-final-v2）。
• 不知道哪个分支是"稳定的"、哪个是"最新的"。
• 合并流程不清晰，谁可以合并到什么分支不明确。
• 发布管理困难，hotfix 和 feature 开发相互干扰。
  Git 工作流就是在 Git 的灵活能力之上建立的一套团队协作规范，明确了分支策略、合并规则和发布流程。

1.1 GitFlow

GitFlow 由 Vincent Driessen 在 2010 年提出，是最早也是最经典的 Git 工作流模型。

1.1.1 分支模型

gitGraph
    commit id: "init"
    branch develop
    branch feature/feature-a
    commit
    checkout develop
    merge feature/feature-a
    branch feature/feature-b
    commit
    checkout develop
    merge feature/feature-b
    branch release/1.0.0
    checkout main
    merge release/1.0.0 tag: "v1.0.0"
    branch hotfix/urgent-fix
    commit
    checkout main
    merge hotfix/urgent-fix tag: "v1.0.1"
    checkout develop
    merge hotfix/urgent-fix

1.1.2 分支类型与职责

分支	存在周期	来源	合并到	命名
main	永久	—	—	main
develop	永久	—	—	develop
feature	临时	develop	develop	feature/xxx
release	临时	develop	main + develop	release/x.y.z
hotfix	临时	main	main + develop	hotfix/xxx

1.1.3 工作流程

Feature 开发：

# 从 develop 创建 feature 分支

git checkout -b feature/user-auth develop

# 开发、提交

git commit -m "feat: 实现用户登录"

# 完成开发，合并回 develop

git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

--no-ff参数强制生成合并提交，保留功能分支的完整历史。
Release 发布：

# 从 develop 创建 release 分支

git checkout -b release/1.0.0 develop

# 在 release 分支上做最终调整

# （版本号更新、文档完善、小 bug 修复）

# 合并到 main（打标签）

git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "v1.0.0 正式发布"

# 合并回 develop（确保 hotfix 变更同步）

git checkout develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0

Hotfix 修复：

# 从 main 创建 hotfix 分支

git checkout -b hotfix/login-crash main

# 修复问题

git commit -m "fix: 修复登录页面崩溃"

# 合并到 main（打标签）

git checkout main
git merge --no-ff hotfix/login-crash
git tag -a v1.0.1 -m "v1.0.1 修复登录崩溃"

# 合并回 develop

git checkout develop
git merge --no-ff hotfix/login-crash
git branch -d hotfix/login-crash

1.1.4 适用场景

• 有明确发布周期的项目（如移动 App、企业软件）。
• 需要同时维护多个版本。
• 团队规模较大（10 人以上），需要严格的分工和流程。

1.2 局限性

• 复杂度高：分支类型多，合并规则复杂，新人学习曲线陡峭。
• 延迟集成：feature 分支可能长期不合并，导致集成冲突。
• 与持续交付理念冲突：多个 release 和 hotfix 分支阻碍了主干随时可部署的目标。

1.3 GitHub Flow

GitHub Flow 由 GitHub 在 2011 年提出，是对 GitFlow 的简化。它假设可以随时部署 main 分支到生产环境。

1.3.1 核心规则

1. main分支永远是可部署的。

2. 任何新工作都从main创建描述性命名的分支。

3. 定期将本地提交推送到远程同名分支。

4. 需要反馈或合并时，创建 Pull Request。

5. 经过审查后合并到main。

6. 合并到main后立即部署。

gitGraph
    commit id: "init"
    branch feature-user-auth
    commit
    checkout main
    merge feature-user-auth tag: "PR → 审查 → 合并 → 部署"
    branch refactor-api
    commit
    checkout main
    merge refactor-api tag: "PR → 审查 → 合并 → 部署"

1.3.2 工作流程

# 所有工作从 main 开始

git checkout main
git pull origin main

# 创建描述性分支

git checkout -b add-two-factor-auth

# 开发并定期推送

git commit -m "feat: 实现双因素认证基础结构"
git push -u origin add-two-factor-auth

# 在 GitHub 上创建 Pull Request

# 经过 CI 检查和代码审查后合并

# 合并后立即清理本地

git checkout main
git pull origin main
git branch -d add-two-factor-auth

1.3.3 适用场景

• 持续部署的 Web 应用。
• SaaS 产品（随时可以发布）。
• 中小型团队（2-10 人），沟通成本低。

1.4 局限性

• 不支持多版本维护：如果需要同时支持 v1.x 和 v2.x，GitHub Flow 没有提供机制。
• 对部署流水线要求高：要求每次合并后都能可靠部署，对自动化测试和部署基础设施有较高要求。
• 不适合有固定发布周期的项目：移动 App 审核周期长，无法做到"合并即部署"。

1.5 GitLab Flow

GitLab Flow 是 GitLab 提出的工作流，融合了 GitFlow 的版本管理能力和 GitHub Flow 的简洁性。

1.5.1 环境分支模型

GitLab Flow 的核心是"环境分支"——每个部署环境对应一个分支：

gitGraph
    commit id: "main"
    branch pre-production
    commit
    branch production
    commit

工作流程：

# feature 开发从 main 分支

git checkout -b feature-new-dashboard main

# ... 开发完成后 MR 到 main ...

# main 自动部署到 staging 环境

# 验证通过后，将 main 合并到 pre-production

# pre-production 验证通过后，合并到 production

每个环境确保只有上级环境验证通过的代码才会流入
。

1.6 版本发布模型

对于需要维护多版本的产品，使用版本分支：

gitGraph
    commit id: "持续开发"
    branch "1.x-stable"
    commit
    branch "1.7-stable"
    checkout "1.x-stable"
    branch "1.8-stable"
    checkout main
    branch "2.x-stable"
    commit
    branch "2.0-stable"

# 从 main 创建版本分支

git checkout -b 2.x-stable main

# 发布时打标签

git tag -a v2.0.0 -m "v2.0.0 发布"

# hotfix 先合并到 main，然后 cherry-pick 到版本分支

git checkout main
git merge hotfix/critical-fix
git checkout 2.x-stable
git cherry-pick <hotfix-commit>

1.7 三种工作流对比

维度	GitFlow	GitHub Flow	GitLab Flow
复杂度	高	低	中
分支数量	5 类	2 类	按环境/版本
持续部署友好	否	是	是
多版本支持	通过 release/hotfix	不支持	通过版本分支
环境管理	无	无	通过环境分支
学习成本	高	低	中
适用团队	大型企业	初创 / SaaS	中型企业
典型产品	企业软件 / SDK	Web SaaS	全场景

1.8 选择工作流的决策框架

graph TD
    A[你的产品是什么类型？]
    A --> B[Web SaaS
随时可部署]
    A --> C[移动 App / 企业软件
同时维护多个版本]
    A --> D[开源项目]

    B --> B1[团队 < 10 人]
    B --> B2[团队 > 10 人 + 多环境]
    B1 --> B1a[GitHub Flow]
    B2 --> B2a[GitLab Flow
环境分支]

    C --> Ca[GitLab Flow
版本分支]

    D --> Da[GitHub Flow]

1.9 文章引用

• GitFlow 原文
• GitHub Flow
• GitLab Flow
• Atlassian Git 工作流对比

📌 本文首发于微信公众号 【运维知识点滴】——专注运维实战干货，微信搜索“运维知识点滴”或扫下方二维码关注，更新不迷路。

微信公众号【运维知识点滴】	微信小程序【A5单据合并&大试卷拆分转A4打印】
运维实战干货 · 关注追更	Word 转 PDF · 试卷/发票打印神器 · 免费

💡 小程序【A5单据合并&大试卷拆分转A4打印】是干嘛的？ 一个 Word 转 PDF 的打印神器，专治“文档版式和打印机对不上”：

• A3 试卷打不出来？ 学校发的电子版试卷多是 A3，家用打印机只吃 A4——上传 Word 一键转换：可缩到一页 A4（页数不变），也可对半拆成两张 A4（1:1 原大、字更清晰），两种模式自选；
• 版式不乱：真实渲染引擎原样转换、绝不重排内容，转出的 PDF 和原 Word 排版一致，公式/表格/图片不跑版；
• 两张 A5 单据拼一张 A4：出租车票、火车票等报销凭证拼版后，一次打印、整齐粘贴；
• 隐私省心：无需注册，转换结果留存 5 天、最多下载 5 次即自动删除，不留任何历史记录；
• 微信扫码即用，免费、免安装，支持 doc / docx（≤50MB）。

上一篇：11. 多仓库依赖怎么管？Git 子模块统一版本一键更新 ｜ 下一篇：13. 仓库越来越大？Git LFS 让图片视频不再撑爆仓库