15、Git工作流：集中式工作流、功能分支工作流、GitFlow工作流、Forking工作流
工作流这件事，说白了就是团队怎么用Git来协作的规矩。没有规矩，不成方圆。我见过太多团队，Git用得乱七八糟，最后合并代码比写代码还痛苦。今天咱们就把四种主流工作流捋一遍，看看它们各自适合什么场景。
集中式工作流
这是最基础的工作流，跟SVN那套思路很像。所有开发人员都在同一个主分支上提交代码。
核心特点：只有一个主干分支，所有人直接往master上提交。
我记得刚入行那会儿，公司用的就是这套。简单是真简单，但坑也是真多。你想想看，五六个开发同时往master上推代码，冲突简直家常便饭。
适用场景：
- 团队规模小（2-3人）
- 项目简单，改动不频繁
- 刚接触Git的团队
我曾经踩过的坑：有一次我改了一个公共工具类，同事也改了同一个文件。我push的时候没拉最新代码，结果把他的改动覆盖了。嗯，从那以后我再也不敢不pull就push了。
功能分支工作流
这个就聪明多了。每个新功能都开一个独立分支，开发完再合并回主分支。我个人习惯用这个工作流，因为它够灵活。
基本流程：
- 从master创建功能分支：
git checkout -b feature/login - 在分支上开发、提交
- 开发完成后，发起Pull Request
- 代码审查通过后，合并到master
小技巧：分支命名最好有规律。我一般用feature/功能名或者fix/问题编号，这样一看就知道这个分支是干嘛的。
为什么推荐这个？因为每个功能都是隔离的。你改你的登录，我改我的注册，互不干扰。就算你改到一半去修Bug，也不会影响其他人。
GitFlow工作流
GitFlow是Vincent Driessen在2010年提出的，算是功能分支工作流的升级版。它定义了更严格的分支模型。
分支类型：
| 分支类型 | 用途 | 命名示例 |
|---|---|---|
| master | 生产环境代码 | master |
| develop | 开发主分支 | develop |
| feature | 新功能开发 | feature/user-profile |
| release | 发布准备 | release/1.2.0 |
| hotfix | 紧急修复 | hotfix/critical-bug |
说实话，GitFlow一开始我觉得太复杂了。但后来在做一个需要严格版本管理的项目时，才发现它的好。每个分支各司其职，谁该干什么清清楚楚。
核心流程：
- 从develop创建feature分支开发新功能
- 功能完成后合并回develop
- 准备发布时，从develop创建release分支
- release分支测试通过后，合并到master和develop
- 线上出Bug，从master创建hotfix分支修复
注意：GitFlow不适合持续交付的场景。因为分支太多，合并操作频繁，反而拖慢节奏。我有个朋友在互联网公司用GitFlow，结果每天光合并分支就花两小时。
Forking工作流
这个在开源项目里最常见。开发者不直接往主仓库提交，而是先fork一份到自己名下，改完再提Pull Request。
工作流程：
- Fork主仓库到自己的GitHub账号
- Clone自己的仓库到本地
- 添加主仓库为上游：
git remote add upstream 主仓库地址 - 创建功能分支开发
- push到自己的仓库
- 发起Pull Request到主仓库
我参与过几个开源项目，用的都是这套。好处很明显——主仓库的代码永远干净，只有经过审查的代码才能合并进去。
我的习惯：每次开发前，先同步上游仓库的最新代码：git fetch upstream && git rebase upstream/master。这样能减少很多冲突。
四种工作流对比
| 工作流 | 复杂度 | 适合团队 | 适合项目 |
|---|---|---|---|
| 集中式 | 低 | 1-3人 | 小型项目 |
| 功能分支 | 中 | 3-10人 | 中型项目 |
| GitFlow | 高 | 5-20人 | 需要版本管理的项目 |
| Forking | 中高 | 不限 | 开源项目 |
选哪个工作流，说白了要看团队和项目。别为了用GitFlow而用GitFlow，也别觉得集中式就low。适合的才是最好的。
我的建议：新手团队先从功能分支工作流开始。等团队成熟了，再考虑要不要上GitFlow。至于Forking工作流，除非你做开源，否则没必要。
最后说一句，工作流是工具，不是枷锁。别被规则束缚住，该灵活就灵活。我见过有人把GitFlow用得比瀑布模型还死板，那就本末倒置了。