GitHub Flow 是目前最受欢迎的 Git 工作流之一，尤其适合现代团队。它由 GitHub 官方提出，设计原则是简单、轻量、专注于持续交付。在 2025 年，随着 CI/CD 的普及和 DevOps 的成熟，GitHub Flow 被广泛视为中小型团队和频繁发布项目的首选工作流（Atlassian、DORA 报告等均推荐）。
相比复杂的多分支模型，GitHub Flow 只使用一个长期分支（通常叫 main），所有变更通过短生命周期的特征分支完成，确保 main 分支始终处于可部署状态。
核心原则
- Anything in the main branch is deployable：main 分支的代码随时可以部署到生产。
- Create descriptive branches off of main：从 main 创建描述性的分支。
- Pull requests are for discussion：使用 Pull Request (PR) 进行代码审查和讨论。
- Deploy from main frequently：频繁从 main 部署。
- Fix bugs in main and ship：修复直接在 main 或通过 hotfix 分支处理。
详细步骤（标准 GitHub Flow 流程）
-
从 main 创建分支：
为每个新功能、bug 修复或实验创建一个新分支。
命令：git checkout -b feature/new-login
分支命名建议：feature/xxx、bugfix/xxx、experiment/xxx。 -
本地开发并频繁提交：
小步提交，消息清晰（推荐 Conventional Commits，如feat: add login page）。 -
推送到远程并打开 Pull Request：
git push origin feature/new-login
在 GitHub 上打开 PR，触发 CI 测试（GitHub Actions 等）。 -
代码审查与讨论：
团队成员审查代码、评论、建议修改。
作者根据反馈继续提交（分支会自动更新 PR）。 -
自动化测试通过后合并：
PR 批准后，直接合并到 main（可选择 squash 合并保持历史干净）。
合并后立即删除分支。 -
从 main 部署到生产：
部署工具（如 GitHub Actions、Vercel、Netlify）自动或手动部署 main。
经典 GitHub Flow 循环图（从 main 分支 → 特征分支 → PR → 合并回 main → 部署）
优点
- 极简：只有一个长期分支，易学易维护。
- 鼓励代码审查：所有变更必须通过 PR。
- 适合连续部署：main 始终可发布，支持每日甚至多次部署。
- 减少合并冲突：分支生命周期短（通常几天内合并）。
- 完美集成 GitHub 生态：PR、Issues、Actions 无缝协作。
适用场景
- 小中型团队。
- Web 应用、SaaS、开源项目。
- 频繁发布（每周多次）。
- 已具备良好 CI/CD 管道的团队。
实施建议
- 小而频繁的提交：每次提交专注单一变更，使用描述性消息（Conventional Commits 规范：feat:、fix: 等）。
- 代码审查必不可少：所有变更通过 PR/MR 审查，至少 1-2 人审批。
- 自动化 CI/CD：每提交自动运行测试、构建、部署。工具如 GitHub Actions、GitLab CI、Jenkins。
- 分支命名规范：如 feature/login、bugfix/issue-123。
- 使用 Rebase 而非 Merge：保持历史线性，避免无意义合并提交（git pull --rebase）。
- 特征标志（Feature Flags）：隐藏未完成功能，避免长分支（工具：Unleash、LaunchDarkly）。
- 主干始终可发布：main 分支随时可部署到生产。
- 每日集成：至少每天合并一次到主干，删除已合并分支。
- 签署提交（Signed Commits）：提升安全性。
- 监控指标：追踪部署频率、变更失败率、合并冲突数（DORA 指标）。
