16、Git工作流（二）：GitHub Flow、GitLab Flow、Forking工作流（开源项目协作模式）
上一章我们聊了 Git Flow，那个分支模型确实经典，但说实话，我在实际项目中很少用它。为什么？因为太复杂了。对于大多数团队来说，尤其是做持续交付的团队，Git Flow 的 release 分支和 hotfix 分支反而成了负担。
这一章，我带你看看另外三种更轻量、更贴合现代 DevOps 理念的工作流：GitHub Flow、GitLab Flow，以及开源项目里最常见的 Forking 工作流。
GitHub Flow：极简主义的代表
GitHub Flow 是 GitHub 官方推荐的工作流。它有多简单？只有一个长期分支——main（或者叫 master）。
我刚开始用 GitHub Flow 时，心里也犯嘀咕：就一个主分支，够用吗？后来发现，其实大部分场景真的够了。
核心规则
- main 分支永远是可部署的。这是铁律，谁都不能往 main 上直接 push 有问题的代码。
- 从 main 拉取 feature 分支。你要开发新功能，就从 main 切出来。
- 定期 push 到远程。别憋在本地，早点让大家看到你的进度。
- 提交 Pull Request。这是代码审查和讨论的入口。
- 合并到 main 后立即部署。理想情况下，合并即上线。
我个人习惯：在 GitHub Flow 里，PR 的标题就是 commit message 的浓缩版。我会在 PR 描述里写清楚「为什么改」和「怎么改」，而不是只写「修复了 bug」。这样 reviewer 看起来省力很多。
什么时候用 GitHub Flow？
- 团队规模小（10人以内）
- 持续部署，每天多次上线
- 产品迭代快，不需要长期维护多个版本
注意：GitHub Flow 对 CI/CD 的要求很高。如果你没有自动化测试和自动化部署，合并到 main 后手动部署，那风险就大了。我曾经见过一个团队，合并后忘了部署，结果线上还是旧代码，排查了半天才发现问题。
GitLab Flow：环境分支的智慧
GitLab Flow 是 GitLab 团队提出的改进版。它解决了 GitHub Flow 的一个痛点：环境管理。
你想想看，GitHub Flow 说「合并到 main 就部署」，但你的环境可能不止一个：开发环境、测试环境、预发布环境、生产环境。难道每次合并都部署到所有环境？显然不合理。
GitLab Flow 的解决方案是：引入环境分支。
典型结构
main（开发主线）
↓
pre-production（预发布）
↓
production（生产）代码从 feature 分支合并到 main，然后通过 merge request 逐步提升到 pre-production，最后到 production。每个环境分支都对应一个真实的部署环境。
避坑指南：我曾经在预发布环境发现了一个 bug，直接在 pre-production 分支上修了。结果后来合并到 main 时产生了冲突。正确的做法是：在 feature 分支上修，然后重新走一遍合并流程。环境分支只用来「提升」代码，不要在上面直接改。
GitLab Flow 的另一种变体：版本分支
如果你的产品需要同时维护多个版本（比如 v1.0、v2.0），GitLab Flow 也支持。做法是创建 v1.0-stable、v2.0-stable 这样的长期分支，bug 修复从 main cherry-pick 到这些分支上。
| 特性 | GitHub Flow | GitLab Flow |
|---|---|---|
| 长期分支数 | 1个（main） | 多个（main + 环境分支） |
| 环境管理 | 隐式（通过 CI/CD） | 显式（通过分支） |
| 版本维护 | 不擅长 | 支持 |
| 适合场景 | 持续部署、小团队 | 多环境、多版本 |
Forking 工作流：开源项目的标配
说到开源项目，Forking 工作流是绕不开的。你想想看，Linux 内核、Kubernetes、React，这些顶级开源项目，哪个不是用 Forking 工作流？
它的核心思想很简单：贡献者没有主仓库的写权限。你要改代码，先 Fork 一份到自己的账号下，然后在自己的仓库里改，最后通过 Pull Request 把改动提交回去。
流程拆解
- Fork 主仓库。在 GitHub 上点一下 Fork 按钮，你的账号下就有了一个副本。
- Clone 你的 Fork。注意，clone 的是你的仓库，不是主仓库。
- 添加 upstream 远程。这一步很多人会忘。你需要把主仓库的地址添加为 upstream，方便后续同步。
- 创建 feature 分支。别在 main 上直接改，养成好习惯。
- 提交 PR。从你的 feature 分支，向主仓库的 main 分支发起 PR。
- 等待 review。项目维护者会审查你的代码，可能会要求修改。
我踩过的坑：有一次我给一个开源项目提 PR，代码写好了，但主仓库已经往前推进了好几个 commit。我的 PR 产生了冲突。当时我直接在 GitHub 上点了一下「Resolve conflicts」，结果把别人的代码搞乱了。正确的做法是：在本地 rebase 到 upstream/main，解决冲突后再 force push。
Forking 工作流的同步策略
这是 Forking 工作流里最容易出问题的地方。我建议你记住这个命令序列：
# 添加 upstream（只需要做一次）
git remote add upstream https://github.com/原仓库/项目.git
# 同步主仓库的最新代码
git fetch upstream
git checkout main
git rebase upstream/main
# 推送到你的 Fork
git push origin main --force警告：--force 要慎用。如果你和别人协作同一个 Fork，force push 会覆盖别人的提交。个人项目无所谓，团队协作时一定要先沟通。
三种工作流的对比
说了这么多，到底该选哪个？我个人的经验是：
- 内部小团队，持续部署 → GitHub Flow。简单直接，少即是多。
- 内部团队，多环境多版本 → GitLab Flow。环境分支让部署流程更清晰。
- 开源项目，外部贡献者 → Forking 工作流。这是唯一的选择，因为你不能给每个贡献者都开写权限。
嗯，其实还有一种情况：大公司内部的大型项目，可能会把 Forking 工作流用在内部。比如我在上一家公司，每个团队 Fork 一个公共仓库，然后通过内部 PR 协作。这样既保证了代码质量，又避免了权限管理的麻烦。
SVG 流程图：三种工作流的核心逻辑
最后说一句：工作流是工具，不是教条。我见过用 GitHub Flow 做得很烂的团队，也见过用 Git Flow 做得风生水起的团队。关键不在于选哪个，而在于团队是否理解并遵守规则。选一个适合你们的，然后坚持下去。