GitHub Flow 工作流

GitHub Flow 是 GitHub 团队使用的工作流，极其简洁，适合持续部署。

GitHub Flow 分支结构

Bash

master（主分支，随时可部署）
   │
   ├─ feature/A → PR → merge → deploy
   │
   ├─ feature/B → PR → merge → deploy
   │
   └─ feature/C → PR → merge → deploy

分支类型

分支	说明
master	主分支，始终可部署状态
feature/*	功能分支，开发完成后合入

GitHub Flow 原则

Bash

1. master 分支始终可部署
2. 功能分支从 master 创建
3. 功能完成后创建 PR
4. 通过审核和测试后合并
5. 合并后立即部署

GitHub Flow 流程

步骤1：创建功能分支

Bash

# 从 master 创建分支
git checkout master
git pull origin master
git checkout -b feature/new-feature

步骤2：开发并提交

Bash

# 开发功能
git add .
git commit -m "feat: 添加新功能"

# 推送到远程
git push -u origin feature/new-feature

步骤3：创建 Pull Request

Bash

# GitHub 网站创建 PR
# 从 feature/new-feature 到 master
# 填写 PR 信息

步骤4：审核和测试

Bash

# 审核者查看 PR
# 运行 CI 测试
# 添加评论或批准

步骤5：合并和部署

Bash

# 合并 PR 到 master
# 合并后立即部署到生产环境
# 验证功能正常

GitHub Flow vs Git Flow

特性	GitHub Flow	Git Flow
分支数量	极少（master + feature）	较多（5种分支）
发布方式	合并即部署	需 release 分支
适用场景	持续部署	传统发布周期
复杂度	简单	复杂
学习成本	低	高

GitHub Flow 适用场景

适用	不适用
Web 应用	需要多版本维护
持续部署项目	有明确发布周期
小型团队	大型企业项目
快速迭代	需要严格版本控制

最佳实践

text

# master 分支保护
# Settings → Branches → Add rule
# Require PR before merging
# Require approvals

# CI 自动测试
# PR 创建时自动运行测试
# 测试通过才能合并

# 部署自动化
# 合并后自动部署
# 或手动触发部署

快速回滚

text

# 如果部署后发现问题
# 快速回滚到上一个版本

# 方法1：回退提交
git revert <commit>

# 方法2：重新部署旧版本
# 部署上一个 tag

# 因为 master 始终可部署
# 回滚非常容易

GitHub Flow 图示

text

开发流程：

master ────●────●────●────●────●──→
           │    │    │
feature A  ●────┘    │
           │         │
feature B  ●─────────┘
           │
           PR → Review → Merge → Deploy

GitHub Flow 简洁高效，是现代持续部署项目的首选工作流。

要点总结

只有一个永久分支 master
功能分支从 master 创建
通过 PR 合入 master
合入后立即部署
master 始终保持可部署状态

📝 发现内容有误？点击此处直接编辑