选择 Git 工作流时，团队常常在集中式、功能分支和 GitFlow 之间犹豫。没有绝对最好的工作流，只有最适合当前团队规模和发布节奏的方案。本文先给出判断路径，再展开三种工作流的细节对比，帮助你快速做出决策。
先判断：你的团队属于哪种情况？
选择 Git 工作流，核心看三个维度：团队规模、发布频率、协作需求。根据以下路径对号入座：
- 团队 ≤ 5 人，发布频繁，功能简单：集中式工作流最直接，所有成员在 master 上提交，冲突少，学习成本低。
- 团队 5-20 人，功能并行开发，需要代码审查：功能分支工作流更合适，每个功能独立分支，通过 Pull Request 合并，保证 master 始终可部署。
- 团队 > 20 人，有固定发布周期，需要维护多个版本：GitFlow 提供严格的分支模型，支持并行开发、预发布和热修复，但流程较重。
如果团队处于成长阶段，建议从功能分支开始，逐步演进到 GitFlow。不要一开始就引入复杂流程，否则团队会陷入分支管理而非开发本身。
三种工作流核心对比
集中式工作流
集中式工作流只有一个长期分支（通常是 master），所有开发者直接提交到该分支。它的优势是简单直接，适合小团队或快速原型开发。但缺点也很明显：多人同时提交容易产生冲突，且没有代码审查机制，错误可能直接进入生产环境。
功能分支工作流
功能分支工作流为每个功能创建独立分支，开发完成后通过 Pull Request 合并回 master。这种模式天然支持代码审查，且 master 始终处于可发布状态。它比集中式更灵活，比 GitFlow 更轻量，是目前最推荐的工作流。
GitFlow 工作流
GitFlow 定义了 master、develop、feature、release、hotfix 五类分支。master 存放正式发布版本，develop 集成开发成果，feature 分支开发新功能，release 分支准备发布，hotfix 分支紧急修复。它适合需要严格版本管理和多版本支持的团队，但流程复杂，不适合持续交付。
操作步骤：从零实施功能分支工作流
以功能分支工作流为例，具体操作如下：
- 基于 master 创建功能分支：
git checkout -b feature/login - 在分支上开发并提交：
git add . && git commit -m "实现登录功能" - 推送分支到远程：
git push origin feature/login - 发起 Pull Request，邀请同事审查代码。
- 审查通过后合并到 master，并删除功能分支。
如果使用 GitFlow，则额外增加 release 和 hotfix 分支的管理，但核心逻辑类似。
取舍与失败条件
集中式的适用边界
集中式工作流在团队超过 5 人时容易失控。如果多人同时修改同一文件，冲突解决会耗费大量时间。此外，没有分支隔离，实验性代码可能污染主分支。若团队需要并行开发，建议尽快切换到功能分支。
功能分支的常见误区
功能分支的误区包括：分支生命周期过长（超过一周），导致合并冲突加剧；忘记定期同步 master，导致合并时大量冲突；Pull Request 流于形式，没有真正审查。建议功能分支控制在 2-3 天内完成，并每日同步 master。
GitFlow 的复杂代价
GitFlow 的失败条件在于：团队没有足够纪律维护分支规范；发布频率高时，release 分支管理成为负担；持续交付场景下，GitFlow 的严格分支模型反而拖慢节奏。如果团队采用 DevOps 和持续部署，建议使用功能分支或 GitHub Flow 的简化版。
常见误区：不要盲目跟风
- 误区一：GitFlow 是标准答案。实际上，很多团队用 GitFlow 后发现流程过重，最终简化。选择工作流应基于实际需求。
- 误区二：集中式没有价值。对于个人项目或极小型团队，集中式依然高效，不必为了“先进”而引入复杂分支。
- 误区三：分支越多越好。分支过多会导致管理混乱，每次合并都需谨慎。保持分支精简是良好实践。
参考资料
本文参考了以下官方文档，以获取版本控制和 Web 开发的最佳实践：
延伸阅读