首页 › Git › 团队协作（在新窗口打开） › Git Flow 与 GitHub Flow

GitHub Flow

最轻量的分支模型，适合持续部署的项目。

规则：

• 只有一个长期分支 main。
• 新功能从 main 创建分支。
• 通过 PR 审查后合并回 main。
• 合并后立即部署。

适合场景：CI/CD 成熟的团队、SaaS 产品、小团队。

Git Flow

经典的分支模型，适合版本发布周期的项目。

分支角色

分支	用途	来源	合并到
main	生产发布版	—	—
develop	日常开发集成分支	main	main
feature/*	新功能开发	develop	develop
release/*	发布准备	develop	main + develop
hotfix/*	紧急修复	main	main + develop

Git Flow 操作

# 创建功能分支
git switch -c feature/my-feature develop
# 开发完成后合并回 develop
git switch develop
git merge --no-ff feature/my-feature

# 创建发布分支
git switch -c release/1.0 develop
# 修复 Bug、更新版本号
# 合并到 main 和 develop
git switch main
git merge --no-ff release/1.0
git tag -a v1.0 -m "Release 1.0"
git switch develop
git merge --no-ff release/1.0

# 创建 Hotfix
git switch -c hotfix/1.0.1 main
# 修复
git switch main
git merge --no-ff hotfix/1.0.1
git tag -a v1.0.1 -m "Hotfix 1.0.1"
git switch develop
git merge --no-ff hotfix/1.0.1

适用场景：版本发布周期明确的软件、移动 App、需要同时维护多版本。

GitLab Flow

结合环境分支的概念，适合有多个部署环境（staging / production）的项目。

环境分支	说明
main	开发主分支
pre-production	预发布环境
production	生产环境

选择建议

场景	推荐工作流
持续部署的 Web 应用	GitHub Flow
版本发布周期的移动/客户端	Git Flow
多环境部署	GitLab Flow
单仓库单团队（< 10 人）	GitHub Flow
多仓库多团队	Git Flow

保护分支

在 GitHub/GitLab 上设置保护分支规则：

• 禁止直接推送到 main/develop。
• 要求 PR 审查：至少 1 人 approve。
• 要求 CI 通过：构建和测试必须绿。
• 要求线性历史：只允许 squash merge。

小结

• GitHub Flow：只有 main，适合持续部署。
• Git Flow：5 种分支（main / develop / feature / release / hotfix），适合版本发布。
• GitLab Flow：按环境分分支（main / pre-prod / production）。
• 选择取决于发布节奏、团队规模和部署模式。
• 保护分支确保 main 分支的稳定性，必须通过 PR 和 CI。

上一节：Pull Request 流程 下一节：git bisect 与 blame

贡献者: 布欧-Lewyon