Appearance
分支策略
概述
良好的分支策略是团队协作的基础，它定义了如何使用分支来组织和管理开发工作。本节将介绍几种常见的分支策略及其适用场景。
功能分支策略
功能分支策略（Feature Branch Workflow）是最简单且常用的分支策略。
核心概念
- 每个新功能都在独立分支上开发
- 功能分支从主分支创建
- 开发完成后合并回主分支
- 主分支始终保持可部署状态
工作流程
main A --- B --- C --- D --- E
\ /
feature-x F --- Gbash
# 1. 从 main 创建功能分支
git checkout main
git pull origin main
git checkout -b feature/user-auth
# 2. 开发功能
git add .
git commit -m "Add user authentication"
# 3. 推送到远程
git push -u origin feature/user-auth
# 4. 创建 Pull Request / Merge Request
# 5. 代码审查通过后合并
# 6. 删除功能分支
git checkout main
git pull origin main
git branch -d feature/user-auth
git push origin --delete feature/user-auth优点
- 主分支始终干净、可部署
- 功能开发相互隔离
- 便于代码审查
- 适合持续集成
缺点
- 长期功能分支可能导致合并冲突
- 需要频繁同步主分支变更
Git Flow 策略
Git Flow 是一个严格的分支模型，适合有计划发布周期的项目。
分支类型
main A ------------------------ B (发布)
\ /
release C --- D --- E ----------- F
\ /
develop G --- H --- I --- J --- K
\ /
feature L --- M- main：生产分支，只接受 release 和 hotfix 的合并
- develop：开发分支，集成所有功能
- feature：功能分支，从 develop 创建
- release：发布分支，准备发布
- hotfix：热修复分支，从 main 创建
工作流程
bash
# 初始化 Git Flow
git flow init
# 开始新功能
git flow feature start user-auth
# 相当于：git checkout -b feature/user-auth develop
# 完成功能
git flow feature finish user-auth
# 相当于：git checkout develop && git merge feature/user-auth
# 开始发布
git flow release start v1.0.0
# 相当于：git checkout -b release/v1.0.0 develop
# 完成发布
git flow release finish v1.0.0
# 合并到 main 和 develop，打标签
# 开始热修复
git flow hotfix start critical-bug
# 相当于：git checkout -b hotfix/critical-bug main
# 完成热修复
git flow hotfix finish critical-bug
# 合并到 main 和 develop优点
- 清晰的分支结构
- 适合版本发布
- 热修复流程完善
缺点
- 分支复杂，学习成本高
- 不适合持续部署
- 长期分支可能导致冲突
GitHub Flow 策略
GitHub Flow 是简化的分支策略，适合持续部署。
核心概念
- 只有一个长期分支：main
- 所有开发都通过功能分支
- 功能分支合并后立即部署
工作流程
main A --- B --- C --- D --- E
\ /
feature F --- Gbash
# 1. 创建功能分支
git checkout -b feature/user-auth
# 2. 开发并提交
git add .
git commit -m "Add user authentication"
# 3. 推送并创建 Pull Request
git push -u origin feature/user-auth
# 4. 代码审查和讨论
# 5. 合并到 main
# 通过 GitHub 界面或命令行
# 6. 立即部署优点
- 简单易懂
- 适合持续部署
- 减少分支管理开销
缺点
- 不适合需要维护多版本的项目
- 缺少发布前的测试阶段
GitLab Flow 策略
GitLab Flow 结合了 Git Flow 和 GitHub Flow 的优点。
环境分支模式
main (开发) A --- B --- C --- D
\ /
pre-production E --- F
\
production G工作流程
bash
# 功能开发
git checkout -b feature/user-auth
git add .
git commit -m "Add user authentication"
git push -u origin feature/user-auth
# 合并到 main（开发环境）
# 通过 Merge Request
# 部署到预生产环境
git checkout pre-production
git merge main
# 部署到生产环境
git checkout production
git merge pre-production优点
- 支持多环境部署
- 灵活性高
- 适合企业级项目
分支命名规范
常见命名模式
bash
# 功能分支
feature/user-authentication
feature/payment-integration
feat/add-login-page
# 发布分支
release/v1.0.0
release/2023.12
# 热修复分支
hotfix/critical-security-patch
hotfix/login-error
# Bug 修复分支
bugfix/issue-123
fix/login-validation
# 实验分支
experiment/new-algorithm
spike/performance-test命名最佳实践
bash
# 好的命名
feature/user-authentication # 清晰描述功能
bugfix/issue-123-login-error # 关联问题编号
hotfix/security-cve-2023-1234 # 关联安全漏洞编号
# 不好的命名
test # 太模糊
my-branch # 不描述目的
feature1 # 使用数字而非描述
fix-bug # 不够具体分支前缀规范
| 前缀 | 用途 | 示例 |
|---|---|---|
feature/ 或 feat/ | 新功能 | feature/user-auth |
bugfix/ 或 fix/ | Bug 修复 | bugfix/login-error |
hotfix/ | 紧急修复 | hotfix/security-patch |
release/ | 发布准备 | release/v1.0.0 |
experiment/ 或 spike/ | 实验性开发 | experiment/new-algo |
docs/ | 文档更新 | docs/api-reference |
refactor/ | 代码重构 | refactor/user-module |
test/ | 测试相关 | test/integration-tests |
策略选择指南
项目类型选择
| 项目类型 | 推荐策略 | 原因 |
|---|---|---|
| 小型项目 | GitHub Flow | 简单高效 |
| Web 应用 | GitHub Flow | 支持持续部署 |
| 开源项目 | GitHub Flow | 便于外部贡献 |
| 企业软件 | GitLab Flow | 支持多环境 |
| 移动应用 | Git Flow | 需要版本管理 |
| 库/框架 | Git Flow | 需要维护多版本 |
团队规模选择
| 团队规模 | 推荐策略 | 原因 |
|---|---|---|
| 1-5 人 | GitHub Flow | 简单易管理 |
| 5-20 人 | GitLab Flow | 平衡复杂度和灵活性 |
| 20+ 人 | Git Flow | 严格的流程控制 |
分支保护规则
设置保护分支
bash
# 在 GitHub/GitLab 设置中配置
# 保护 main 分支
# 规则示例：
# - 禁止直接推送
# - 需要 Pull Request
# - 需要代码审查
# - 需要通过 CI 测试
# - 需要管理员批准本地钩子
bash
# .git/hooks/pre-commit
#!/bin/bash
branch=$(git rev-parse --abbrev-ref HEAD)
# 禁止直接提交到 main
if [ "$branch" = "main" ]; then
echo "直接提交到 main 分支被禁止！"
echo "请使用功能分支和 Pull Request。"
exit 1
fi总结
- 选择分支策略应根据项目特点和团队规模
- 功能分支策略适合大多数项目
- Git Flow 适合有版本发布周期的项目
- GitHub Flow 适合持续部署
- 分支命名应清晰、一致
- 保护重要分支，强制代码审查
下一步
学习完分支策略后，建议继续学习：