Git 工作流策略对比

你的 Git 分支策略直接影响团队发布代码的速度、部署出错的频率以及合并冲突的痛苦程度。2026 年三种主流策略是 Gitflow、GitHub Flow 和主干开发（Trunk-Based Development）。每种策略在发布控制、开发速度和运维复杂度之间做出不同的权衡。本指南深入讲解每种策略，提供实际示例和决策框架帮助你做出选择。

Gitflow：结构化发布管理

Gitflow 由 Vincent Driessen 于 2010 年提出，使用多个长期分支来管理发布。它是三种策略中最结构化的，拥有专门的功能分支、发布分支和热修复分支。Gitflow 专为有计划发布周期的项目设计，每次发布都经过正式的测试和稳定阶段。

该模型使用五种分支类型：main（生产代码）、develop（集成分支）、功能分支（新功能开发）、发布分支（发布稳定化）和热修复分支（紧急生产修复）。代码从功能分支流入 develop，从 develop 流入发布分支，最终流入 main。

Gitflow 分支结构

# Gitflow 实践

# 1. 开始新功能
git checkout develop
git pull origin develop
git checkout -b feature/user-authentication

# 开发功能...
git add .
git commit -m "feat: 添加 JWT 认证中间件"
git commit -m "feat: 添加登录/登出端点"

# 2. 完成功能 — 合并回 develop
git checkout develop
git merge --no-ff feature/user-authentication
git push origin develop

# 3. 创建发布分支
git checkout -b release/2.1.0
git commit -m "fix: 修正会话超时处理"

# 4. 完成发布 — 合并到 main 和 develop
git checkout main
git merge --no-ff release/2.1.0
git tag -a v2.1.0 -m "Release 2.1.0"

# 5. 生产热修复
git checkout main
git checkout -b hotfix/2.1.1
git commit -m "fix: 修补关键 XSS 漏洞"
git checkout main
git merge --no-ff hotfix/2.1.1
git tag -a v2.1.1 -m "Hotfix 2.1.1"

GitHub Flow：简单持续

GitHub Flow 是围绕单一原则构建的轻量级分支策略：main 分支中的所有代码都是可部署的。开发者从 main 创建短期功能分支，通过 Pull Request 进行代码审查，然后直接合并回 main。main 分支始终处于可部署状态。

GitHub Flow 专为持续交付设计。每个合并的 Pull Request 都可以（且经常是）立即部署。没有发布分支、没有 develop 分支、没有热修复分支。这种模型的简洁性使其在实践持续部署的团队中极为流行。

# GitHub Flow 实践

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

# 2. 清晰的提交信息
git commit -m "feat: 添加搜索索引构建器"
git commit -m "feat: 实现 Fuse.js 模糊搜索"
git commit -m "test: 添加搜索结果排序测试"

# 3. 推送并创建 Pull Request
git push -u origin add-search-functionality

# 4. 审查通过后合并到 main
git checkout main
git merge --squash add-search-functionality
git commit -m "feat: 添加带键盘快捷键的模糊搜索 (#142)"
git push origin main

# 5. 自动部署到生产环境

主干开发：最大速度

主干开发（TBD）将简单性发挥到极致：所有开发者直接提交到单一分支（trunk/main），或使用非常短期的分支（持续数小时而非数天）。主干始终处于可发布状态，因为每次提交都是小型的、经过测试的、自包含的。

TBD 需要根本不同的思维方式。开发者不是在分支上构建完整功能然后合并，而是将功能拆分为微小的、可独立部署的增量。未完成的功能隐藏在功能标志后面。核心纪律是：每次提交到主干的代码必须安全可部署。

# 主干开发实践

# 选项 A：直接提交到主干
git checkout main
git pull origin main

# 小型、自包含的变更
git commit -m "feat: 添加搜索输入组件（功能标志隐藏）"
git push origin main  # 触发 CI/CD

# 下一个小变更
git commit -m "feat: 添加搜索 API 端点"
git push origin main

# 功能标志示例
const flags = {
  SEARCH_ENABLED: process.env.SEARCH_ENABLED === 'true',
};

// 渐进式推出
// 1. 内部团队启用
// 2. 5% 用户启用
// 3. 50% 用户启用
// 4. 100% — 移除标志

策略对比

从关键维度比较三种策略，找到最适合你团队的方案：

CI/CD 集成

每种策略与 CI/CD 流水线的集成方式不同。流水线的复杂度应与分支策略匹配。

# GitHub Actions — GitHub Flow 的 CI/CD
name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm run build

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: npx vercel --prod --yes

分支命名约定

一致的分支命名提高可追溯性，支持 CI/CD 自动化，并使 git 日志更可读：

Pull Request 最佳实践

• 保持 PR 小型化：目标控制在 400 行以内。大型 PR 会被草草审核而非认真审查。将大功能拆分为一系列小的、可合并的 PR。
• 编写描述性的 PR 标题和说明。包含改了什么、为什么改、如何测试。链接相关的 Issue 或 Ticket。
• 使用 PR 模板标准化审查者需要的信息。包含描述、测试步骤、截图（如有 UI 变更）和检查清单。
• 合并前至少需要一个批准。对关键路径（认证、支付、数据迁移）要求两位审查者。
• 合并前运行所有 CI 检查。阻止测试失败、lint 错误或类型错误的 PR 合并。
• 功能分支优先使用压缩合并（squash merge），保持 main 分支历史干净线性。每个压缩提交代表一个完整的功能或修复。

提交信息约定

约定式提交（Conventional Commits）提供结构化格式，支持自动化更新日志、语义化版本和更好的 git 历史：

# 约定式提交格式
# <类型>(<范围>): <描述>
#
# 类型:
# feat:     新功能（次版本号递增）
# fix:      Bug 修复（补丁版本号递增）
# docs:     仅文档变更
# refactor: 代码重构
# test:     添加/修复测试
# chore:    构建流程、依赖

# 示例:
git commit -m "feat(auth): 添加 OAuth 2.0 Google 登录"
git commit -m "fix(api): 处理支付网关的空响应"
git commit -m "refactor(db): 从原生 SQL 迁移到 Prisma ORM"

# 破坏性变更（主版本号递增）:
git commit -m "feat(api)!: 将认证从 API Key 改为 OAuth"

决策框架

根据你的团队和项目特征，使用此框架选择正确的策略：

FAQ