Git 分支策略对比：Gitflow、主干开发与 GitHub Flow

Git 分支策略：实用对比

选择分支策略会影响团队交付速度、发布稳定性以及开发人员日常开销。没有普遍正确的答案——正确的策略取决于团队规模、部署频率和产品成熟度。

三种主要策略

1. 主干开发（Trunk-Based Development）

每个人都频繁提交到单个分支（main 或 trunk）——至少每天一次。允许短期特性分支（最多 1-2 天），但合并要快。

main: A──B──C──D──E──F──G  (从此处部署)
                │
feature/x:      C──D  (48 小时内合并)

核心实践：

• 特性标志（Feature flags）对用户隐藏未完成的工作
• 每次提交都运行自动化测试套件
• CI/CD 将每个通过的提交部署到生产环境（或预发布环境）
• 代码审查快速进行（当天）

适用场景：

• 拥有强大自动化测试的高绩效团队
• 持续部署的 SaaS 产品
• 1-30 名工程师的团队
• 部署频率最重要时（DORA 指标）

实际用户： Google、Facebook、Netflix

# 主干开发：简单工作流
git checkout main
git pull
# 进行修改
git add .
git commit -m "feat: add user export endpoint"
git push origin main

# 短期特性分支
git checkout -b feat/user-export
# 工作 1-2 天
git push origin feat/user-export
# 打开 PR，获取审查，当天合并
git checkout main && git pull
git branch -d feat/user-export

2. GitHub Flow

一种简化策略：一个主分支，每次变更使用特性分支，通过拉取请求合并。没有发布分支。

main: ────A────────B────────C────  (始终可部署)
          │                 │
feature1: A──x──x──(PR)     │
                    feature2: B──x──(PR)

步骤：

1. 从 main 分支，使用描述性名称
2. 进行提交（分支存活直到合并）
3. 打开拉取请求
4. 讨论、审查和迭代
5. 从分支部署到预发布/预览环境
6. 合并到 main 并部署

适用场景：

• 持续部署的 Web 应用或 API
• 直接从 main 部署的团队
• 开源项目（贡献者熟悉）
• 想要简单易学的工作流时

# GitHub Flow
git checkout -b feat/oauth-login
# 工作、提交、推送
git push -u origin feat/oauth-login
# 在 GitHub/GitLab 上打开 PR
# 审查和 CI 通过后：
# 通过 PR UI 合并
# 部署 main

# 清理
git checkout main
git pull
git branch -d feat/oauth-login
git push origin --delete feat/oauth-login

3. Gitflow

一种结构化策略，包含特性、发布和热修复的专用分支。由 Vincent Driessen 于 2010 年提出。

main:    ───────────────────────1.0.0──────────2.0.0──
                                   │                │
release: ─────────────────────1.0-rc──merge──      │
                                             │
develop: ──A──B──C──D──E──F──G──────merge────H──I──J──
         │                 │
feature/x: A──x──x──(merge)│
feature/y:       B──x──x──(merge)

分支：

• main — 仅生产发布，打标签
• develop — 集成分支，所有特性合并至此
• feature/* — 单个特性，从 develop 分支
• release/* — 发布准备，从 develop 分支
• hotfix/* — 紧急生产修复，从 main 分支

# 安装 gitflow 工具
brew install git-flow-avh

# 初始化
git flow init

# 开始一个特性
git flow feature start user-authentication
# ... 开发 ...
git flow feature finish user-authentication  # 合并到 develop

# 开始一个发布
git flow release start 1.2.0
# 升级版本，更新变更日志
git flow release finish 1.2.0  # 合并到 main 和 develop，给 main 打标签

# 开始一个热修复
git flow hotfix start fix-payment-bug
# ... 修复 ...
git flow hotfix finish fix-payment-bug  # 合并到 main 和 develop

适用场景：

• 有版本发布的软件（库、移动应用、桌面应用）
• 同时支持多个版本的团队
• 有固定发布周期的项目
• 需要清晰审计追踪每个发布内容时

策略对比

提交消息约定

一致的提交消息可提高 git 日志可读性，并支持自动化工具（变更日志、语义版本控制）。

常规提交格式

<type>(<scope>): <subject>

[optional body]

[optional footer]

类型：

feat(auth): add OAuth2 login with Google
fix(api): handle null response from payment gateway
docs(readme): update setup instructions for Docker
chore(deps): upgrade React to 18.3.1
feat!: redesign user API (BREAKING CHANGE)

! 后缀表示破坏性变更。这与语义版本控制集成：feat 增加次版本号，fix 增加补丁号，破坏性变更增加主版本号。

分支命名约定

# 特性分支
feat/user-authentication
feat/TICKET-123-add-export

# 错误修复
fix/login-redirect-loop
fix/TICKET-456-null-pointer

# 发布
release/1.2.0
release/2026-Q2

# 热修复
hotfix/payment-timeout
hotfix/1.1.1

# 杂项/基础设施
chore/upgrade-dependencies
ci/add-integration-tests

合并 vs 变基

# 合并：保留完整历史，创建合并提交
git checkout main
git merge feature/oauth-login

# 变基：线性历史，重写提交
git checkout feature/oauth-login
git rebase main
git checkout main
git merge feature/oauth-login  # 快进

# 压缩合并：每个 PR 一个提交
git merge --squash feature/oauth-login
git commit -m "feat: add OAuth login"

指南：

• 使用 merge 将完成的特性合并到共享分支
• 使用 rebase 用最新的 main 更新特性分支（PR 之前）
• 使用 squash 当 PR 包含许多你不想保留在历史中的修复提交时
• 永远不要变基共享分支（main、develop）

→ 使用 Git Memo 按需查询 Git 命令。