GitHub Flow

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

Gitブランチ戦略

GitHub Flow とは

GitHub Flow は、main ブランチとフィーチャーブランチだけで運用するシンプルなブランチ戦略である。GitHub の Scott Chacon が 2011 年 8 月に提唱した。原典では、GitHub 社内で git-flow を採らない理由として「常時デプロイしていてリリースという区切りが無い」ことが挙げられており、リリースを中心に据えた分岐を落として簡素化した運用として示されている。Git Flow の複雑さを排除し、継続的デプロイに最適化されている。

ワークフロー

main からブランチを切り、プルリクエストを経て main へ戻すまでの手順は次のとおりである。

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 を本番にデプロイ

7. マージ済みのブランチを削除
   git push origin --delete feature/add-login

Git Flow との比較

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

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

ルール

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

公式ドキュメントが手順として挙げているのはブランチ作成からブランチ削除までで、デプロイは含まれていない。マージ後の即時デプロイは 2011 年の原典が置いた前提であり、GitHub Flow を名乗るなら main へのマージがそのまま本番反映になるようデプロイを自動化しておく必要がある。人手でデプロイを挟むと main とデプロイ済みの内容がずれ、「main は常にデプロイ可能」という 1 番目のルールが崩れる。

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 の保護設定は次の組み合わせが最小構成になる。同じ内容はリポジトリのルールセットでも設定でき、複数ブランチや組織全体へまとめて適用したい場合はそちらを使う。

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 型の運用が向く。承認プロセスが厳格な場合やデプロイ頻度が低い場合は、main へのマージと本番反映を切り離し、タグやリリースブランチ単位でデプロイを管理する。なお、トランクベース開発は短命ブランチで main へ頻繁に統合する点で GitHub Flow と近く、これらの制約の答えにはならない。

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

この記事は役に立ちましたか?

関連用語

関連する記事