IT 技書の森

GitHub Flow

main ブランチとフィーチャーブランチだけで運用するシンプルなブランチ戦略

Gitブランチ戦略

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 との比較

観点 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 との連携

# 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 の背景や設計思想は関連書籍に詳しい。

関連用語