GitHub Flow vs Git Flow：その「慣習」が、あなたの開発スピードを殺している。
テックリードとして現場を見ていて痛感するのは、「とりあえずGit Flowで」という思考停止が、現代の高速なデリバリーサイクルをどれほど阻害しているかという事実だ。
かつての重量級リリースプロセスを支えたGit Flowは、現代のCI/CD環境では「過剰防衛」になりがちだ。今日は、GitHub FlowとGit Flowの本質的な設計思想を解剖し、現場で迷わないための「最適解」を伝授する。
—
1. 思想の衝突：Git Flowという「城壁」vs GitHub Flowという「流水」
Git Flow：大規模・リリース管理の要塞
Git Flowは、`develop`と`master`を軸に、`feature`, `release`, `hotfix`を厳格に切り分ける。
- メリット: 複数バージョンの並行保守が必要なSaaS以前のパッケージ製品や、リリース日が固定された厳格なプロジェクトには適している。
- 現場の現実: 「マージ地獄」と「コンフリクトの温床」。CIが通るまでの待ち時間と、ブランチ間の同期コストがチームの生産性を食いつぶす。
GitHub Flow：継続的デリバリーの極致
`main`ブランチは常にデプロイ可能。機能追加はブランチを切り、即座にプルリクエスト（PR）を作成する。
- メリット: シンプルさ。PRがそのままコミュニケーションのハブとなり、CIが全てをガードする。
- 現場の現実: デプロイ頻度が上がれば上がるほどリスクは小さくなる。現代のWeb開発において、これが「デフォルト」であるべきだ。
結論: 「リリース日を設けて制御する」必要がある場合のみGit Flowを使え。それ以外はGitHub Flowを選択せよ。
—
2. 開発スピードを劇的に高める「プロの武器」
ツールを使いこなす者は、マウスを触らない。
必須のキーボードショートカット（GitHub.com）
- `g` + `i`: Issuesへ移動
- `g` + `p`: Pull Requestsへ移動
- `.` (ドット): GitHub Codespacesが起動。 ブラウザ上で即座にコード修正が可能。
- `Ctrl + Enter`: コメントやPR作成の即時送信（マウス不要のフロー）
入れるべき「神」プラグイン
- GitHub Copilot: もはや必須。特にGitHub ActionsのYAMLを書く際のボイラープレート生成能力は異常。
- Octotree: 大規模リポジトリでディレクトリツリーを表示。コードレビュー時に「全体像」を把握する速度が段違いになる。
- Refined GitHub: GitHubのUIに「あったらいいな」を全て詰め込む。マージボタンの誤爆防止や、ステータスの視覚化など、チームの衛生状態を保つために必須。
—
3. 実践：CI/CDを加速させる「神YAML」構成例
GitHub Actionsの最適化は、チームのデプロイ速度に直結する。単にテストを回すだけでなく、「いかにキャッシュを効かせるか」が腕の見せ所だ。
.github/workflows/ci.yml
name: Fast CI
on:
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# node_modulesをキャッシュし、インストール時間を数分単位で短縮
- name: Cache dependencies
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
- run: npm ci
# 変更があったファイルのみテストする（テストスイートが巨大な場合）
- name: Run tests
run: npm test — –changedSince=main
—
4. チーム開発における「絶対ルール」
技術的なフロー以上に、チームの「規約」がボトルネックを解消する。
1. PRのサイズを極小化せよ: 1PR = 1機能。300行を超えるPRは「読み手への嫌がらせ」であり、レビューが疎かになる。
2. 保護ブランチ（Branch Protection Rules）の徹底:
- `Require pull request reviews before merging` を必須にする。
- `Require status checks to pass before merging` を設定し、CIが通らないコードは物理的にマージ不能にする。
3. 設定のコード化: `.github/CODEOWNERS`を活用せよ。特定のディレクトリ（例: インフラ設定）の変更には、必ずテックリードの承認が必要になるよう自動制御する。
.github/CODEOWNERS
/infra/ @tech-lead-team
/src/ @feature-team
—
終わりに：ツールは「文化」に従う
GitHub Flowを導入したからといって、チームの生産性が魔法のように上がるわけではない。重要なのは、「CIが落ちたら即座に修正する文化」と「PRを通じて仕様を議論する文化」だ。
Git Flowという古い鎧を脱ぎ捨て、GitHub Flowという身軽な装備で、デリバリーのスピードを極限まで加速させてほしい。君の書くコードが、次のリリースを支える強力な翼になることを期待している。