15、Git工作流（一）：集中式工作流、功能分支工作流、Git Flow工作流详解
聊到团队协作，Git 工作流是个绕不开的话题。说白了，工作流就是一套约定——大家怎么拉分支、怎么合并、怎么发布。我见过不少团队，Git 用得挺溜，但协作起来还是一团乱麻，问题就出在没定好规矩。
今天咱们先聊三种最经典的工作流：集中式、功能分支、还有 Git Flow。这三种各有各的适用场景，我挨个给你拆开讲讲。
集中式工作流：小团队的入门之选
集中式工作流，说白了就是把 SVN 那套习惯搬到 Git 上。只有一个主干分支 main（或者叫 master），所有人都在这个分支上提交。
流程大概是这样的：
- 从
main拉取最新代码 - 本地修改、提交
- 推送到远程
main - 如果推送失败（别人先推了），先拉取合并再推送
嗯，听起来很简单对吧？但这里有个坑——冲突会非常频繁。我记得刚带团队那会儿，有个 5 人小项目用集中式工作流，每天光解决冲突就要花掉一两个小时。你想想看，几个人同时改同一个文件，谁先推谁占便宜，后面的人就得手动合并。
main 分支搞崩了，回退都费了半天劲。从那以后，超过 3 个人的项目，我坚决不用集中式。
功能分支工作流：让每个功能独立发育
功能分支工作流，就是在集中式的基础上，给每个功能开一个独立的分支。开发完了再合并回 main。这个改进看似简单，但效果立竿见影。
具体做法：
- 从
main拉出一个新分支，比如feature/login - 在这个分支上专心开发登录功能
- 开发完成后，发起 Pull Request（或者 Merge Request）
- 代码评审通过后，合并回
main
我个人习惯，分支命名用 feature/ 前缀，后面跟功能名，比如 feature/user-profile、feature/payment。这样一看分支名就知道在做什么。
功能分支工作流的好处很明显：每个功能独立开发，互不干扰。就算你改得乱七八糟，也不会影响主干。等代码稳定了再合并回去。
但这里有个问题——合并时机怎么把握？ 我见过两种做法：一种是开发完一次性合并，另一种是每天从 main 往功能分支合并一次，保持同步。我个人倾向后者，虽然多了几步操作，但能避免最后合并时出现“地狱级冲突”。
Git Flow：重型武器，适合正式发布流程
Git Flow 是 2010 年 Vincent Driessen 提出的，算是最经典的工作流之一。它定义了五种分支：
| 分支类型 | 命名示例 | 用途 |
|---|---|---|
| main | main | 只存放正式发布的代码 |
| develop | develop | 日常开发的主分支 |
| feature | feature/* | 开发新功能 |
| release | release/* | 准备发布版本 |
| hotfix | hotfix/* | 紧急修复线上问题 |
Git Flow 的核心逻辑是这样的：日常开发在 develop 分支上进行。功能开发从 develop 拉出 feature 分支，完成后合并回 develop。当要发布时，从 develop 拉出 release 分支，只做 bug 修复和文档更新，不再加新功能。最后 release 合并到 main 和 develop。线上出紧急 bug 时，从 main 拉出 hotfix 分支，修复后合并回 main 和 develop。
说实话，我第一次看 Git Flow 的流程图时，觉得有点复杂。但真正用起来，你会发现它把发布流程管得死死的，特别适合有固定发布周期的项目。
main 上的提交都对应一个正式发布版本，回退到任何一个历史版本都很方便。
下面这张图是我自己画的 Git Flow 流程，你看一眼就明白了：
看到没？feature 分支从 develop 拉出，合并回去。release 分支从 develop 拉出，合并到 main 和 develop。hotfix 从 main 拉出，合并回两边。这个结构把开发、发布、紧急修复分得清清楚楚。
develop 拉了个 hotfix 分支。结果修复里不小心带上了还没测试完的新功能，差点把线上搞崩。记住：hotfix 必须从 main 拉，只修 bug，不加功能。
三种工作流怎么选？
我个人的经验是：
- 集中式工作流：适合 1-3 人、快速原型、内部工具。说白了，人少怎么搞都行。
- 功能分支工作流：适合 3-10 人、持续交付、没有固定发布周期的项目。我现在大部分项目都用这个。
- Git Flow：适合 10 人以上、有固定发布周期（比如每月一发）、需要严格版本管理的项目。比如一些 toB 的产品，客户对版本号很敏感，Git Flow 就很合适。
嗯，这里要提醒一句：工作流不是越复杂越好。我见过一些团队，一上来就上 Git Flow，结果光分支管理就把新人搞晕了。你想想看，如果团队就 5 个人，每天发版好几次，Git Flow 那套 release 分支反而成了累赘。
好了，今天先聊这三种。下一章咱们继续讲 GitHub Flow 和 GitLab Flow，还有怎么在实际项目中落地。到时候我会拿我最近做的一个电商项目当例子，把踩过的坑都抖出来。