Git 分支管理策略:从 Git Flow 到 Trunk-Based

分支是 Git 最强大的特性,但"能用分支"和"会用分支"是两回事。没有策略的仓库很快就会变成乱麻:功能分支长期不合并、主分支频繁出问题、评审形同虚设。本文梳理三种主流策略,帮你找到适合团队的那一种。

1. 为什么需要分支策略

分支策略解决三个问题:主干何时可发布?功能代码在哪开发?出问题如何快速回滚?没有约定,冲突和事故只是时间问题。

2. Git Flow:最经典的重型方案

Git Flow 定义了五类分支,适合有明确版本发布周期的项目(如桌面软件、SDK):

• main:只存放可发布的稳定版本。
• develop:日常集成的开发主干。
• feature/*:功能分支,从 develop 拉出,完成后合并回 develop。
• release/*:发布前准备分支,只修 bug 不开发新功能。
• hotfix/*:线上紧急修复,从 main 拉出,修完同时合并回 main 和 develop。

# 从 develop 拉功能分支
git checkout develop
git checkout -b feature/login

# 功能完成后合并回 develop
git checkout develop
git merge --no-ff feature/login

# 发布前拉 release 分支
git checkout -b release/1.2.0 develop
git commit -m "release: 准备 1.2.0"

Git Flow 流程严谨,但分支多、操作繁琐,小团队往往觉得"太重"。

3. GitHub Flow:轻量而主流

GitHub Flow 只有两条规则:main 永远可部署 + 一切改动走功能分支 + Pull Request。

git checkout -b feat/add-search
# ... 开发、提交、推送 ...
git push -u origin feat/add-search
# 在 GitHub 上发起 Pull Request → 评审 → 合并
git checkout main
git pull origin main

它把"评审"作为质量闸门,适合持续部署的 Web 项目,新成员一天就能上手,是互联网团队的主流选择。

4. Trunk-Based Development:极致集成

Trunk-Based 要求所有人频繁(甚至每天)把小改动直接合并到主干,功能分支存活不超过一两天,配合特性开关(Feature Flag)隐藏未完成的功能。

• 优点:合并冲突最少,持续集成真正落地。
• 代价:要求团队纪律性强、测试覆盖率高,不适合新手团队。

5. 分支命名规范

无论选哪种策略,命名规范都能让分支"见名知意"。推荐格式:类型/简述,类型用 feat、fix、docs、refactor、chore,简述用短横线连接的小写英文,可带需求编号:

git checkout -b feat/user-profile
git checkout -b fix/payment-timeout-4821
git checkout -b docs/api-usage

6. 保护规则与合并方式

光有策略还不够,要用规则强制执行。在 GitHub / GitLab 上给主干分支开启保护:

• Require PR review:至少一名 reviewer 通过才能合并。
• Require CI 通过:测试红了不允许合并。
• 禁止直接 push:所有改动必须走 PR。

合并方式上,推荐 --no-ff(保留合并记录)或 Squash(压缩成一个提交),前者历史真实、后者历史干净,团队二选一并写进文档。

💡 学习建议:先在自己的个人项目上实践 GitHub Flow,养成"功能分支 + PR + 主干可部署"的肌肉记忆;等团队规模变大、发布节奏变复杂,再渐进引入 Git Flow 的 release / hotfix 分支,不要一开始就上重型方案。