GitHub Flow
main ブランチとフィーチャーブランチだけで運用するシンプルなブランチ戦略
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 Flow | Git Flow |
|---|---|---|
| ブランチ数 | 2 (main + feature) | 5+ (main, develop, feature, release, hotfix) |
| 複雑さ | 低い | 高い |
| デプロイ頻度 | 高い (マージ = デプロイ) | 低い (リリースブランチ経由) |
| 適するチーム | 小〜中規模、CI/CD 成熟 | 大規模、リリースサイクルが長い |
| main の状態 | 常にデプロイ可能 | リリース時のみ更新 |
ルール
公式ドキュメントが手順として挙げているのはブランチ作成からブランチ削除までで、デプロイは含まれていない。マージ後の即時デプロイは 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 の背景や設計思想は関連書籍に詳しい。
この記事は役に立ちましたか?
関連用語
Git Flow
feature、develop、release、hotfix、main の 5 種類のブランチで開発を管理するブランチ戦略
フィーチャーブランチとは - 機能ごとに独立したブランチで開発しマージする Git ワークフロー
機能ごとに独立したブランチを作成し、完成後にメインブランチにマージする Git ワークフロー
CI/CD
コードの変更を自動的にビルド / テスト / デプロイするパイプライン
トランクベース開発
全開発者が 1 つのメインブランチに頻繁にコミットし、長寿命ブランチを避ける開発手法
Git
分散型バージョン管理システムで、ソースコードの変更履歴を管理する
CodePipeline
AWS のマネージド CI/CD サービスで、ソースからデプロイまでのパイプラインを自動化する
関連する記事
技術書ランキングの決定版はどれか - IT エンジニア本大賞の歴代大賞と言及数データで読む
技術書ランキングを探している人向けに、検証可能な 2 つのデータ (IT エンジニア本大賞の歴代大賞 2014-2026 年と、当サイトの Qiita / Zenn 言及数ランキング) を整理。歴代受賞作の一覧表と、ランキングを選書に活かす方法を解説します。
チーム開発 / マネジメント本ガイド - 技術リーダーが読むべき本
チーム開発、1on1、技術マネジメントを学べる技術書の選び方を紹介。メンバー時代からマネージャーまで、段階別の読書ロードマップを解説します。
「あとで読む」ブックマークが 100 件を超えたら本を買え
ブラウザのブックマークに技術記事を溜め込んでいませんか。断片的な記事を 100 件読むより、同じテーマの本を 1 冊読む方が効率的な理由を解説します。