团队选分支策略别纠结，持续发布选 GitHub Flow，版本发布选 Git Flow。

选型决策指南

如果团队刚起步或做 Web 应用，直接用 GitHub Flow，只有一个主分支，开发完就合并。如果是做客户端软件或需要严格版本号管理，用 Git Flow，区分开发分支和发布分支。别为了显得专业强行上 Git Flow，流程复杂会增加维护成本。

核心判断标准：

• 发布频率：一天部署多次选 GitHub Flow；几周发布一个版本选 Git Flow。
• 版本管理：需要同时维护多个历史版本（如 v1.0, v1.1）选 Git Flow。
• 基础设施：没有自动化测试和 CI/CD 流水线，慎用 GitHub Flow。

核心机制差异

Git Flow 是 2010 年提出的经典模型，基于“版本发布”理念，假设一段时间后才产出新版本，所以需要 develop 分支存放开发版，master 分支存放稳定版。GitHub Flow 是简化版，配合“持续发布”，代码一有变动就部署，main 分支随时可发布，不需要长期维护 develop 分支。

注意分支命名：GitHub 新建仓库默认主分支为 main，而传统 Git Flow 工具默认主分支为 master。混用时需统一命名，避免配置冲突。

Git Flow 实操配置

Git Flow 不是 Git 自带命令，需要先安装扩展工具。

1. 安装 git-flow 工具

# macOS
brew install git-flow

# Ubuntu/Debian
apt-get install git-flow

# Windows (Git Bash)
通常随 Git for Windows 安装，或手动下载 git-flow-win

2. 初始化工作流

在项目根目录执行初始化，注意确认主分支名称（main 或 master）。

git flow init -d
# -d 表示使用默认分支名，若主分支是 main 而非 master，需手动指定
# 提示 Production branch: 输入 main 或 master
# 提示 Development branch: 输入 develop

3. 功能开发与发布

# 开始新功能
git flow feature start login-feature

# 完成功能（合并回 develop）
git flow feature finish login-feature

# 开始发布版本
git flow release start v1.0.0

# 完成发布（合并回 master 和 develop，打标签）
git flow release finish v1.0.0

GitHub Flow 实操配置

GitHub Flow 依赖平台功能，核心是分支 + Pull Request。

1. 分支操作

# 从 main 分支创建功能分支
git checkout main
git pull
git checkout -b feature/login-page

# 推送分支
git push origin feature/login-page

2. 创建 Pull Request (PR)

1. 登录 GitHub 仓库页面，顶部会出现黄色提示条，点击 "Compare & pull request"。
2. 填写 PR 标题和描述，关联 Issue（如有）。
3. 指定 Reviewer 进行代码审查。
4. 审查通过后，点击 "Merge pull request" 合并到 main。
5. 合并后删除远程功能分支。

3. 保护主分支

在 Settings -> Branches 中，为 main 分支添加规则，要求 PR 审查和 CI 检查通过才能合并，防止直接 push 破坏主干。

自动化与验证

GitHub Flow 强依赖自动化，建议配置简单的 CI 流程验证代码。

1. 配置 GitHub Actions

在 `.github/workflows/ci.yml` 添加以下配置，每次 PR 自动运行测试。

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Tests
        run: echo "Running tests..." # 替换为实际测试命令

2. 验证生效方法

• 检查分支列表：执行 git branch -a。Git Flow 应看到 master/main 和 develop 长期存在；GitHub Flow 应主要看到 main 和短期功能分支。
• 观察部署日志：GitHub Flow 模式下部署频率应较高且自动化程度高。
• 确认代码位置：团队成员应清楚当前代码在哪个分支，避免合并错分支。

常见风险与排查

• git-flow 命令报错：确认已安装扩展工具，而非原生 Git 命令。检查初始化时的分支命名是否与仓库实际主分支一致。
• GitHub Flow 主干不稳定：如果缺乏自动化测试，直接合并到 main 可能导致线上故障。务必开启分支保护规则。
• 工具默认配置冲突：大多数工具默认 master 为主分支，Git Flow 开发却在 develop，需调整工具配置或统一使用 main。
• 过度设计：小团队用 Git Flow 会增加沟通成本，没必要维护两个长期分支。
• 合并冲突频繁：长期分支（如 develop）若不及时合并 main 的更新，容易产生冲突。建议定期 sync。

参考来源

• 基础入门 - 版本控制 - 团队协作流程:Git Flow 与 GitHub Flow
• 一文弄懂 Gitflow、Github flow、Gitlab flow 的工作流
• 代码管理的艺术：你的团队是否还在为 Git 分支管理头疼？
• 常见分支模式优劣对比 | 学习笔记 - 阿里云开发者社区
• Git 最佳实践：分支管理