01. 分支策略的重要性
没有分支策略的团队就是灾难——所有人往一个分支上 commit，代码冲突天天发生，永远不知道哪个版本能发布。分支策略是团队的协作规则。
分支策略解决这几个问题：
- 新功能怎么开发？（在哪个分支、怎么合回主线）
- 生产环境跑了什么代码？（发布分支还是主分支）
- 紧急 bug 怎么修？（怎么绕过正在开发的新功能快速修）
- 开发中代码和稳定代码怎么隔离？
常见的三种工作流：Git Flow（最经典但有点重）、GitHub Flow（简单轻量）、GitLab Flow（环境驱动）。选哪种看团队规模和发布节奏。
bash
# 不管哪种工作流，核心分支就两类：
# 长期分支——main/master、develop（一直存在）
# 短期分支——feature、hotfix、release（完成后就删）
# 查看分支
git branch -a02. Git Flow——经典企业级工作流
Git Flow 是最经典的分支模型，适合有明确发布周期的项目：
两个永久分支：
master/main——只有发布代码，每个 commit 都是一个发布版本（打 tag）。
develop——开发集成分支，所有 feature 合到这里。
三个临时分支：
feature/xxx——从 develop 分出，开发完成后合回 develop。
release/x.x.x——从 develop 分出，做发布前的最后测试和修 bug（不改新功能）。完成后合到 master 和 develop。
hotfix/x.x.x——从 master 分出修紧急 bug，完成后合到 master 和 develop。
优点：结构清晰，角色的职责分明。缺点：对持续部署的项目来说太重了——release 分支的存在拖慢了发布节奏。
bash
# Git Flow 分支操作
git checkout -b feature/new-login develop # 开始新功能
git checkout develop && git merge feature/new-login # 合回开发
git branch -d feature/new-login # 删除功能分支
git checkout -b release/1.2.0 develop # 开始发布准备
git checkout master && git merge release/1.2.0 # 发布到主分支
git tag -a v1.2.0 -m "Release 1.2.0" # 打版本标签
git checkout develop && git merge release/1.2.0
git checkout -b hotfix/bug-123 master # 紧急修 bug
git checkout master && git merge hotfix/bug-123
git tag -a v1.1.1 -m "Hotfix 1.1.1"03. GitHub Flow——简单现代的轻量工作流
GitHub Flow 比 Git Flow 简单得多，适合持续部署的项目：
只有一条主分支 main——始终是可部署的稳定代码。
所有开发在 feature 分支上——从 main 分出来，开发完成后通过 Pull Request 合回 main。
合回 main 后立刻部署——这就是持续部署的理念：main 上的代码总是能发布的。
优势：简单、部署快、适合 SaaS 产品。劣势：缺少 release 流程，修 hotfix 也得走完整的 feature branch 流程，紧急时不够快。
适合：Web 应用、微服务、持续部署的团队。你的代码合并到 main 后立刻自动部署到生产。
bash
# GitHub Flow
git checkout -b feature/new-login main
git add . && git commit -m "feat: new login"
git push origin feature/new-login
# 创建 Pull Request
# Code Review
# Merge to main
# 自动部署（CI/CD）
git checkout main && git pull
git branch -d feature/new-loginGitHub Flow 的核心思想：main 分支永远可以部署。任何 feature 分支都是简短的（一两天内合回），不会长期分叉。
04. Trunk-Based Development（主干开发）
Trunk-Based Development 比 GitHub Flow 更激进——所有人直接往 trunk（main）分支上频繁提交小改动，feature 分支生命周期超短（几小时到一天）。
核心原则：
1. 小批量频繁提交——每天多次合到 main，减少合并冲突。
2. Feature Flag——新功能代码合到 main 但用开关控制是否启用。功能开关不开，代码在生产跑着但用户看不到。
3. 全面的自动化测试——没时间手动测，全靠 CI 保障质量。
4. Pair Programming / Code Review——每个 commit 至少两个人看过。
Google 和 Facebook 用的就是这种模式。对团队要求高——测试、监控、feature flag 基建要到位。小团队基础没做好的话反而容易出问题。
bash
# Trunk-Based 开发
# 开发者 A
git pull origin main
git checkout -b tiny-feature
git commit -m "add partial logic"
git push && create PR && merge # 几小时内就合回
# 新功能用 feature flag 控制
if (featureFlags.newLogin) {
// 新代码路径
} else {
// 旧代码路径
}Trunk-Based 的精髓是 feature flag——代码可以部署到生产但不启用。新功能在后台悄悄开发测试，确认稳定后一键打开。
05. 选哪种工作流
没有银弹，看场景选：
Git Flow——适合有固定发布周期的传统软件（如 App、开源项目）。版本号明确，每次发布有测试期。团队规模中到大。
GitHub Flow——适合持续部署的 Web 应用、SaaS 产品。改了就部署，不需要维护多个发布版本。团队规模不限。
Trunk-Based——适合技术能力强的团队，追求最高发布频率。测试自动化程度高，有成熟的 Feature Flag 体系。小团队谨慎。
混合方案——取各家之长。比如用 Git Flow 的 hotfix 分支理念 + GitHub Flow 的轻量 PR 流程。不用照搬教条。
bash
# 各工作流的标签对比
# Git Flow: master, develop, feature/*, release/*, hotfix/*
# GitHub Flow: main, feature/*
# Trunk-Based: main, tiny-short-lived-branches
# 切换工作流基本就是团队约定，Git 本身不管
# 重要的是大家在同一个规则下协作知识测验
第 1/5 题正确 0
Git Flow 有几个永久分支？
下一节
下一节 Git 高级技巧