Gitブランチ戦略入門｜Git Flow・GitHub Flow・Trunk-Basedの使い分け

チーム開発でGitを使うとき、「ブランチをどう切るか」は生産性に直結する重要な問題です。明確なルールがなければ、コンフリクトの頻発やリリースの混乱を招きます。

この記事では、代表的な3つのブランチ戦略――Git Flow、GitHub Flow、Trunk-Based Development――を比較解説し、チーム規模やプロジェクト特性に応じた最適な選び方を紹介します。

ブランチ戦略とは何か

ブランチ戦略とは、チーム全体で統一するブランチの作成・命名・マージのルールです。適切なブランチ戦略を採用することで、以下のメリットが得られます。

並行開発の効率化：複数の機能を同時に開発してもコンフリクトが起きにくい
リリース管理の明確化：どのコードがリリース対象かが明確になる
品質の担保：レビューとテストのフローが自然に組み込まれる
障害対応の迅速化：ホットフィックスのフローが定まっている

ブランチ戦略を選ぶ前に考えるべきこと

最適なブランチ戦略は、プロジェクトの特性によって異なります。以下の要素を考慮しましょう。

チームの規模：2〜3人なのか、10人以上なのか
リリース頻度：毎日デプロイするのか、月1回なのか
プロダクトの種類：Webサービスか、パッケージソフトか
CI/CDの成熟度：自動テスト・自動デプロイの仕組みがあるか

Git Flow：リリース管理が厳密なプロジェクト向け

Git Flowは、2010年にVincent Driessen氏が提唱したブランチモデルです。リリースサイクルが明確で、複数バージョンの保守が必要なプロジェクトに適しています。

Git Flowの5つのブランチ

main：本番環境のコード。常にリリース可能な状態
develop：開発の統合ブランチ。次のリリースに向けた最新コード
feature/*：個別の機能開発用。developから分岐し、developにマージ
release/*：リリース準備用。developから分岐し、mainとdevelopにマージ
hotfix/*：緊急修正用。mainから分岐し、mainとdevelopにマージ

Git Flowの実践

# 機能開発の開始
git checkout develop
git pull origin develop
git checkout -b feature/user-authentication

# 開発作業...
git add .
git commit -m "feat: ユーザー認証機能を実装"

# developにマージ（プルリクエスト経由が推奨）
git checkout develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication
git push origin develop

# リリース準備
git checkout develop
git checkout -b release/1.2.0

# バージョン番号の更新、最終テスト、バグ修正
git commit -m "chore: バージョンを1.2.0に更新"

# リリース
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin main --tags

# developにもマージ
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

# 緊急修正（ホットフィックス）
git checkout main
git checkout -b hotfix/1.2.1

# 修正作業...
git commit -m "fix: セッション切れのバグを修正"

# mainにマージ
git checkout main
git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m "Hotfix 1.2.1"

# developにもマージ
git checkout develop
git merge --no-ff hotfix/1.2.1
git branch -d hotfix/1.2.1

Git Flowのメリット・デメリット

メリット：

リリースプロセスが明確で、品質管理がしやすい
複数バージョンの並行保守に対応可能
ホットフィックスのフローが定義されている

デメリット：

ブランチの種類が多く、運用が複雑
マージの頻度が高く、コンフリクトが発生しやすい
継続的デプロイには不向き

GitHub Flow：シンプルで継続的デプロイ向け

GitHub Flowは、GitHubが提唱するシンプルなブランチ戦略です。mainブランチとfeatureブランチの2種類だけを使い、mainへのマージ後すぐにデプロイするモデルです。

GitHub Flowのルール

mainブランチは常にデプロイ可能：壊れたコードがmainに入ることは許されない
作業はfeatureブランチで行う：mainから分岐し、意味のある名前を付ける
プルリクエストでレビュー：必ずコードレビューを経てマージ
マージしたらすぐデプロイ：CI/CDパイプラインで自動デプロイ

GitHub Flowの実践

# ブランチ作成
git checkout main
git pull origin main
git checkout -b feature/add-search-functionality

# 開発作業（小さなコミットを積み重ねる）
git add .
git commit -m "feat: 検索フォームのUIを実装"

git add .
git commit -m "feat: 検索APIとの連携を実装"

git add .
git commit -m "test: 検索機能のテストを追加"

# リモートにプッシュ
git push -u origin feature/add-search-functionality

# GitHubでプルリクエストを作成
# → コードレビュー
# → CIテストの通過を確認
# → マージ（Squash mergeまたはMerge commit）
# → 自動デプロイ

# GitHub CLIを使ったプルリクエスト作成
gh pr create \
  --title "feat: 検索機能を追加" \
  --body "## 概要
検索フォームとAPIを実装しました。

## テスト
- [x] 単体テスト追加
- [x] ローカルで動作確認済み" \
  --base main

GitHub Flowのメリット・デメリット

メリット：

ルールがシンプルで理解しやすい
継続的デプロイとの相性が良い
プルリクエストベースでレビュー文化が定着しやすい

デメリット：

リリースバージョンの管理が別途必要
充実したCI/CDパイプラインが前提
複数バージョンの並行保守には不向き

Trunk-Based Development：高速な開発サイクル向け

Trunk-Based Development（TBD）は、全員がtrunk（main）ブランチに頻繁にコミットし、長寿命のブランチを作らないアプローチです。Google、Facebook、Microsoftなどの大企業が採用していることで知られています。

Trunk-Based Developmentのルール

短命のブランチのみ：ブランチは1〜2日以内にマージ
小さな変更を頻繁にマージ：大きなfeatureブランチは作らない
フィーチャーフラグの活用：未完成の機能をコードに含めつつ、本番では非表示にする
強力な自動テスト：trunkが常にデプロイ可能であることを保証

Trunk-Based Developmentの実践

# 短命ブランチで作業（1-2日以内にマージ）
git checkout main
git pull origin main
git checkout -b short-lived/add-search-input

# 最小限の変更をコミット
git add .
git commit -m "feat: 検索入力フォームを追加（フラグで非表示）"

# すぐにプルリクエスト → レビュー → マージ
git push -u origin short-lived/add-search-input

フィーチャーフラグの実装例

// featureFlags.ts
const featureFlags = {
  SEARCH_ENABLED: process.env.FEATURE_SEARCH === 'true',
  NEW_DASHBOARD: process.env.FEATURE_NEW_DASHBOARD === 'true',
};

export default featureFlags;

// SearchComponent.tsx
import featureFlags from './featureFlags';

function App() {
  return (
    <div>
      <Header />
      {featureFlags.SEARCH_ENABLED && <SearchBar />}
      <MainContent />
    </div>
  );
}

# 環境変数でフラグを制御
# 開発環境: FEATURE_SEARCH=true
# 本番環境: FEATURE_SEARCH=false（準備ができたらtrueに変更）

フィーチャーフラグにより、未完成のコードをtrunkにマージしても本番環境には影響しません。機能が完成したらフラグをオンにするだけでリリースできます。

Trunk-Based Developmentのメリット・デメリット

メリット：

マージコンフリクトが最小限に抑えられる
継続的インテグレーションの理念に最も忠実
デプロイ頻度を最大化できる

デメリット：

高度な自動テスト基盤が必須
フィーチャーフラグの管理が必要
チーム全体の技術レベルが求められる

3つの戦略を比較する

3つのブランチ戦略を、具体的な観点で比較します。

チーム規模とリリース頻度での選択

小規模チーム（2〜5人）× 頻繁なリリース：GitHub FlowまたはTrunk-Based
中規模チーム（5〜15人）× 定期リリース：GitHub FlowまたはGit Flow
大規模チーム（15人以上）× 高頻度デプロイ：Trunk-Based Development
パッケージソフト × バージョン管理が必要：Git Flow

プロダクトタイプでの選択

Webサービス（SaaS）：GitHub FlowまたはTrunk-Based。デプロイの頻度が高い
モバイルアプリ：Git FlowまたはGitHub Flow。App Storeの審査サイクルに合わせる
OSSライブラリ：Git Flow。セマンティックバージョニングとの相性が良い
社内ツール：GitHub Flow。シンプルさが重要

コミットメッセージとブランチ命名の規約

ブランチ戦略を運用する上で、コミットメッセージとブランチの命名規約も統一しましょう。

Conventional Commitsの採用

# コミットメッセージの形式
# type(scope): description

feat(auth): ユーザー認証機能を追加
fix(api): レスポンスヘッダーのCORS設定を修正
docs(readme): セットアップ手順を更新
refactor(db): クエリの最適化
test(auth): ログインテストを追加
chore(deps): 依存パッケージを更新

ブランチ命名規約

# 推奨される命名パターン
feature/user-authentication      # 新機能
fix/login-session-timeout        # バグ修正
hotfix/critical-security-patch   # 緊急修正
refactor/database-queries        # リファクタリング
docs/api-documentation           # ドキュメント

# Issue番号を含める場合
feature/123-user-authentication
fix/456-login-session-timeout

ブランチ保護ルールの設定

# GitHub CLIでブランチ保護ルールを設定
gh api repos/{owner}/{repo}/branches/main/protection \
  --method PUT \
  --field required_status_checks='{"strict":true,"contexts":["ci/test"]}' \
  --field required_pull_request_reviews='{"required_approving_review_count":1}' \
  --field enforce_admins=true

実践：GitHub Flowの導入手順

最も汎用性が高いGitHub Flowを例に、チームへの導入手順を紹介します。

ステップ1：ブランチ保護を設定

GitHubリポジトリのSettings > Branches > Branch protection rulesで以下を設定します。

Require a pull request before merging（プルリクエスト必須）
Require approvals: 1（最低1人の承認）
Require status checks to pass（CIの通過必須）
Require branches to be up to date（最新のmainとの同期必須）

ステップ2：CI/CDワークフローを設定

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run test
      - run: npm run build

ステップ3：マージ戦略を決定

# Squash merge: 複数コミットを1つにまとめてマージ（推奨）
# → 履歴がきれいになる。featureブランチの試行錯誤が隠れる

# Merge commit: マージコミットを作成
# → 履歴が正確に残る。ブランチの分岐・統合が視覚的にわかる

# Rebase merge: リベースしてfast-forwardマージ
# → 線形な履歴になる。マージコミットが作られない

GitHub FlowではSquash mergeが最も人気があります。featureブランチ内の試行錯誤のコミットが1つにまとめられ、mainの履歴が読みやすくなります。