GitHub Flow

GitHub Flow とは

GitHub Flow は、main ブランチとフィーチャーブランチだけで運用するシンプルなブランチ戦略である。GitHub が 2011 年に提唱した。Git Flow の複雑さを排除し、継続的デプロイに最適化されている。

ワークフロー

ワークフローを図で示す。

1. main からフィーチャーブランチを作成
   git checkout -b feature/add-login

2. コミットを積む
   git commit -m "Add login form"

3. プルリクエストを作成
   gh pr create --title "Add login feature"

4. コードレビュー + CI テスト

5. main にマージ
   gh pr merge --squash

6. main を本番にデプロイ

Git Flow との比較

Git Flow との主な違いを以下に比較する。

観点	GitHub Flow	Git Flow
ブランチ数	2 (main + feature)	5+ (main, develop, feature, release, hotfix)
複雑さ	低い	高い
デプロイ頻度	高い (マージ = デプロイ)	低い (リリースブランチ経由)
適するチーム	小〜中規模、CI/CD 成熟	大規模、リリースサイクルが長い
main の状態	常にデプロイ可能	リリース時のみ更新

ルール

1. main は常にデプロイ可能な状態を保つ
2. 作業は必ずフィーチャーブランチで行う
3. プルリクエストでコードレビューを受ける
4. CI テストが通ったらマージする
5. マージしたら即座にデプロイする

GitHub Actions との連携

GitHub Actions との 連携の例を示す。

# main へのマージで自動デプロイ
name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - run: aws s3 sync out/ s3://${{ secrets.BUCKET_NAME }}

ブランチ保護ルール

ブランチ保護ルールを図で示す。

main ブランチの保護:
  ✅ Require pull request reviews (1 人以上)
  ✅ Require status checks to pass (CI テスト)
  ✅ Require branches to be up to date
  ❌ Allow force pushes (禁止)

適さないケース

• 複数バージョンを同時にサポートする必要がある (ライブラリ、OS)
• リリース承認プロセスが厳格 (金融、医療)
• デプロイ頻度が低い (月 1 回以下)

これらのケースでは Git Flow やトランクベース開発を検討する。

GitHub Flow の背景や設計思想は関連書籍に詳しい。