Git 工作流：团队协作的分支策略

Git 是程序员的必备技能，但很多人日常只用到 add、commit、push 三板斧。当团队规模扩大、项目复杂度上升时，一套清晰的 Git 分支策略能让协作效率翻倍，避免"合并地狱"。

为什么需要分支策略？

想象这样一个场景：三个开发者同时在 main 分支上开发，A 在做用户模块，B 在做支付模块，C 在修 Bug。大家互相覆盖代码，合并冲突不断——这就是没有分支策略的后果。

分支策略的核心目标是：让每个人在独立的空间里开发，完成后安全地合并回主线，互不干扰。

Git Flow：经典的分支模型

Git Flow 是最经典的分支策略，适合有明确版本发布节奏的项目。它定义了五种分支：

main（主分支）— 始终保持可发布状态，每次合并代表一次正式发布
develop（开发分支）— 日常开发的集成分支，包含下一个版本的最新功能
feature/*（功能分支）— 从 develop 拉出，开发完成后合并回 develop
release/*（发布分支）— 从 develop 拉出，用于版本发布前的测试和修复
hotfix/*（热修复分支）— 从 main 拉出，用于紧急修复线上 Bug

# 开发新功能
git checkout develop
git checkout -b feature/user-login
# ... 开发完成后
git checkout develop
git merge --no-ff feature/user-login

# 发布版本
git checkout develop
git checkout -b release/1.0.0
# ... 测试修复后
git checkout main
git merge --no-ff release/1.0.0
git tag v1.0.0

GitHub Flow：更轻量的选择

如果你的项目采用持续部署（CI/CD），Git Flow 可能显得过于复杂。GitHub Flow 是更轻量的替代方案，只有两条核心规则：

main 分支始终是安全的、可部署的
所有改动通过 Pull Request 合并到 main

# 1. 从 main 创建功能分支
git checkout main
git checkout -b add-search-feature

# 2. 开发并提交
git add .
git commit -m "feat: add search functionality"

# 3. 推送到远程，创建 Pull Request
git push origin add-search-feature

# 4. Code Review 通过后合并到 main

GitHub Flow 的优势在于简单直观，适合小团队和快速迭代的项目。Netflix、Shopify 等公司都在使用这种模式。

Trunk-Based Development：极致效率

对于经验丰富的团队，还可以考虑主干开发（Trunk-Based Development）。所有人直接在 main 分支上开发，通过短生命周期的分支（不超过一天）和 Feature Flag 来控制功能的发布。

这种模式要求团队有良好的代码审查习惯和完善的自动化测试覆盖，但回报是极高的集成频率和极少的合并冲突。

如何选择？

没有最好的分支策略，只有最适合团队的策略。

选择时考虑三个因素：团队规模、发布频率、CI/CD 成熟度。小团队快速迭代选 GitHub Flow，大团队多版本并行选 Git Flow，成熟团队追求极致效率选 Trunk-Based。

Commit 规范

无论选择哪种分支策略，统一的 Commit 信息规范都很重要。推荐使用 Conventional Commits：

feat: 新增用户登录功能
fix: 修复支付页面金额计算错误
docs: 更新 API 文档
style: 格式化代码
refactor: 重构用户模块的数据访问层
test: 添加用户注册模块的单元测试
chore: 升级依赖版本

规范的 Commit 信息让 Git 历史变成清晰的项目演进记录，方便追溯和生成 Changelog。

小结

Git 分支策略是团队协作的基础设施。在项目初期就确定好分支策略和 Commit 规范，能避免很多后期的混乱。建议从 GitHub Flow 开始——它足够简单，又能覆盖大多数场景，等团队成熟后再根据需要升级到更复杂的策略。