GitHub Flow 工作流

概述

GitHub Flow 是 GitHub 推荐的一种简化工作流模型,由 Scott Chacon 在 2011 年提出。相比 Git Flow,它更加简单直接,特别适合持续部署和快速迭代的项目。

GitHub Flow 的核心理念是:

只有一个长期分支: main(或 master)
其他分支都是短期分支
任何修改都通过 Pull Request 进行
持续部署是常态

简化流程

基本流程

GitHub Flow 的工作流程非常简单:

main ──●────●────●────●────●──
        \    /      \    /
feature  ●──●        ●──●

从 main 分支创建新分支
进行开发并提交更改
创建 Pull Request
代码审查和讨论
合并到 main 分支
自动部署到生产环境

详细步骤

1. 创建分支

bash

# 确保 main 分支是最新的
git checkout main
git pull origin main

# 创建新的特性分支
git checkout -b feature/add-user-profile

# 分支命名建议
# feature/xxx - 新功能
# fix/xxx - 修复问题
# refactor/xxx - 重构代码
# docs/xxx - 文档更新

2. 开发和提交

bash

# 进行开发工作
git add .
git commit -m "Add user profile component"

# 推送到远程
git push origin feature/add-user-profile

# 继续开发
git add .
git commit -m "Add profile image upload"
git push origin feature/add-user-profile

3. 创建 Pull Request

在 GitHub 网页上创建 Pull Request:

访问仓库页面
点击 "Compare & pull request" 按钮
填写 PR 标题和描述
指定审查人员
点击 "Create pull request"

4. 代码审查

bash

# 审查者拉取 PR 分支进行本地测试
git fetch origin
git checkout feature/add-user-profile

# 运行测试
npm test

# 提出修改建议
# 在 GitHub 网页上添加评论

5. 合并到主分支

bash

# 在 GitHub 网页上点击 "Merge pull request"
# 或使用命令行合并

git checkout main
git pull origin main
git merge --no-ff feature/add-user-profile
git push origin main

# 删除已合并的分支
git branch -d feature/add-user-profile
git push origin --delete feature/add-user-profile

部署集成

持续部署流程

GitHub Flow 天然支持持续部署:

yaml

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run tests
        run: npm test
      
      - name: Build
        run: npm run build
      
      - name: Deploy to production
        run: |
          # 部署脚本
          ./deploy.sh

预发布环境

可以为每个 Pull Request 创建预发布环境:

yaml

# .github/workflows/preview.yml
name: Deploy Preview

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  deploy-preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Deploy preview environment
        run: |
          # 部署到预览环境
          PREVIEW_URL="https://pr-${{ github.event.pull_request.number }}.preview.example.com"
          ./deploy-preview.sh $PREVIEW_URL
          
      - name: Comment PR
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '🚀 Preview deployed to: ${{ env.PREVIEW_URL }}'
            })

部署检查清单

在合并前确保:

markdown

## 部署前检查

- [ ] 所有测试通过
- [ ] 代码审查完成
- [ ] 无安全漏洞
- [ ] 性能测试通过
- [ ] 文档已更新
- [ ] 变更日志已更新

Pull Request 最佳实践

PR 标题和描述

markdown

## 标题格式

feat: 添加用户个人资料功能

## 描述模板

### 变更内容
- 添加用户个人资料页面
- 实现头像上传功能
- 添加个人资料编辑表单

### 变更原因
用户需要能够查看和编辑自己的个人资料信息

### 测试计划
- [ ] 单元测试已添加
- [ ] 手动测试完成
- [ ] 跨浏览器测试通过

### 截图
(添加相关截图)

### 相关 Issue
Closes #123

PR 规模控制

bash

# 保持 PR 小而专注
# 理想情况: 200-400 行代码变更

# 如果变更太大,考虑拆分为多个 PR
# 例如:
# PR 1: 添加 API 接口
# PR 2: 添加前端组件
# PR 3: 添加集成测试

代码审查清单

markdown

## 审查者检查清单

### 功能性
- [ ] 代码实现了预期功能
- [ ] 边界情况已处理
- [ ] 错误处理完善

### 代码质量
- [ ] 代码清晰易读
- [ ] 遵循编码规范
- [ ] 无重复代码
- [ ] 命名规范合理

### 测试
- [ ] 单元测试覆盖
- [ ] 测试用例合理
- [ ] 所有测试通过

### 性能
- [ ] 无性能问题
- [ ] 数据库查询优化
- [ ] 无内存泄漏

### 安全
- [ ] 无安全漏洞
- [ ] 输入验证完善
- [ ] 敏感数据保护

分支保护规则

配置分支保护

在 GitHub 仓库设置中配置:

yaml

# 分支保护规则 (Settings -> Branches -> Add rule)

Branch name pattern: main

Rules:
  ☑ Require a pull request before merging
    ☑ Require approvals: 1
    ☑ Dismiss stale pull request approvals when new commits are pushed
    ☑ Require review from Code Owners
  
  ☑ Require status checks to pass before merging
    ☑ Require branches to be up to date before merging
    Status checks: 
      - ci/tests
      - ci/lint
      - security/scan
  
  ☑ Require signed commits
  
  ☑ Include administrators

CODEOWNERS 文件

# .github/CODEOWNERS

# 默认所有文件的所有者
* @team-lead

# 前端代码
/src/**/*.js @frontend-team
/src/**/*.css @frontend-team

# 后端代码
/api/**/*.go @backend-team

# 文档
/docs/ @documentation-team
README.md @documentation-team

# 配置文件
*.yml @devops-team
Dockerfile @devops-team

适用场景

适合使用 GitHub Flow 的场景

持续部署项目
- 每天多次部署
- 自动化测试完善
- 快速迭代需求
小型到中型团队
- 团队成员少于 20 人
- 需要简单高效的工作流
- 避免复杂的分支管理
SaaS 产品
- Web 应用程序
- 移动应用后端
- API 服务
开源项目
- 社区贡献者参与
- 需要透明的开发流程
- 便于外部贡献者参与

不适合使用 GitHub Flow 的场景

多版本维护项目
- 需要维护多个发布版本
- 有长期支持版本
- 建议使用 Git Flow
严格发布周期
- 固定的发布时间窗口
- 需要详细的发布计划
- 建议使用 Git Flow
企业级应用
- 需要严格的版本控制
- 复杂的发布流程
- 建议使用 GitLab Flow

工具集成

GitHub CLI

bash

# 安装 GitHub CLI
# macOS
brew install gh

# 创建 PR
gh pr create --title "feat: add user profile" --body "描述内容"

# 查看 PR 列表
gh pr list

# 检查 PR 状态
gh pr status

# 合并 PR
gh pr merge --squash

# 查看检查状态
gh pr checks

自动化工具

bash

# 使用 Husky 进行提交前检查
npm install husky @commitlint/cli @commitlint/config-conventional

# .husky/pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npm run lint
npm test

# .husky/commit-msg
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no -- commitlint --edit "$1"

常见问题

如何处理紧急修复?

bash

# 从 main 创建 hotfix 分支
git checkout main
git pull origin main
git checkout -b hotfix/fix-login-issue

# 修复问题
git commit -m "fix: resolve login timeout issue"
git push origin hotfix/fix-login-issue

# 创建紧急 PR
gh pr create --title "fix: login timeout issue" --label "hotfix"

# 合并后立即部署

如何处理长期运行的特性?

bash

# 定期从 main 更新
git checkout feature/long-feature
git pull origin main

# 或使用 rebase
git checkout feature/long-feature
git fetch origin
git rebase origin/main

# 强制推送(注意:仅在自己的分支上使用)
git push origin feature/long-feature --force

如何回滚错误的部署?

bash

# 方法1: 创建回滚 PR
git checkout main
git pull origin main
git checkout -b revert/broken-feature
git revert <commit-hash>
git push origin revert/broken-feature

# 创建 PR 并合并

# 方法2: 直接回滚(紧急情况)
git checkout main
git reset --hard <previous-good-commit>
git push origin main --force

总结

GitHub Flow 是一个简单而强大的工作流模型,特别适合现代软件开发:

优势:

简单易学: 流程清晰,学习成本低
持续部署: 天然支持持续部署
代码审查: 强制代码审查,提高代码质量
透明度高: 所有变更都有记录可查

局限性:

版本管理: 不适合多版本维护
发布控制: 缺少专门的发布分支
适用范围: 不适合所有项目类型

选择 GitHub Flow 的关键因素:

团队规模和经验
项目部署频率
版本管理需求
自动化测试覆盖度

对于大多数现代 Web 应用和持续部署项目,GitHub Flow 是一个优秀的选择。

GitHub Flow 工作流 ​

概述 ​

简化流程 ​

基本流程 ​

详细步骤 ​

1. 创建分支 ​

2. 开发和提交 ​

3. 创建 Pull Request ​

4. 代码审查 ​

5. 合并到主分支 ​

部署集成 ​

持续部署流程 ​

预发布环境 ​

部署检查清单 ​

Pull Request 最佳实践 ​

PR 标题和描述 ​

PR 规模控制 ​

代码审查清单 ​

分支保护规则 ​

配置分支保护 ​

CODEOWNERS 文件 ​

适用场景 ​

适合使用 GitHub Flow 的场景 ​

不适合使用 GitHub Flow 的场景 ​

工具集成 ​

GitHub CLI ​

自动化工具 ​

常见问题 ​

如何处理紧急修复? ​

如何处理长期运行的特性? ​

如何回滚错误的部署? ​

总结 ​

GitHub Flow 工作流

概述

简化流程

基本流程

详细步骤

1. 创建分支

2. 开发和提交

3. 创建 Pull Request

4. 代码审查

5. 合并到主分支

部署集成

持续部署流程

预发布环境

部署检查清单

Pull Request 最佳实践

PR 标题和描述

PR 规模控制

代码审查清单

分支保护规则

配置分支保护

CODEOWNERS 文件

适用场景

适合使用 GitHub Flow 的场景

不适合使用 GitHub Flow 的场景

工具集成

GitHub CLI

自动化工具

常见问题

如何处理紧急修复?

如何处理长期运行的特性?

如何回滚错误的部署?

总结