Git ワークフロー完全ガイド｜GitFlow・GitHub Flow・Trunk Based の使い分け

Git は事実上のバージョン管理の標準ですが、「どのブランチ戦略を使うべきか」はチームによって異なります。この記事では、代表的な3つのワークフロー（GitFlow、GitHub Flow、Trunk Based Development）の特徴と使い分けを解説します。

主要な3つのワークフロー

1. GitFlow（伝統的）

• リリース周期が固定
• 複雑だが体系的
• エンタープライズ向け

2. GitHub Flow（シンプル）

• 継続的デプロイ向け
• ブランチが少ない
• 中小規模プロジェクト向け

3. Trunk Based Development（モダン）

• 短命ブランチ中心
• 高頻度デプロイ
• 成熟したチーム向け

GitFlow

2010年に Vincent Driessen が提唱した伝統的なワークフロー。5種類のブランチを使い分けます。

main      ─●─────────●──────●──── (リリース版)
           │         │      │
develop   ─●──●──●──●──●──●●─────── (開発統合)
              │     │      │
feature1 ────●──●──●        │
feature2       ─────●──●────●
             hotfix   release

ブランチの役割

ブランチ	目的
main	本番リリース版
develop	次期リリースの統合
feature/*	機能開発（develop から分岐）
release/*	リリース準備（develop から分岐）
hotfix/*	本番緊急修正（main から分岐）

ワークフロー例

# feature ブランチを作成
git checkout -b feature/user-auth develop

# 開発完了後、develop にマージ
git checkout develop
git merge --no-ff feature/user-auth

# リリース準備
git checkout -b release/1.2.0 develop
# バージョン番号更新、テスト等
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0

メリット

• 並行リリースの管理がしやすい
• 本番バージョンが明確
• 緊急対応フローが体系化されている

デメリット

• 複雑で学習コストが高い
• ブランチが多く管理が煩雑
• 継続的デプロイには向かない

GitHub Flow

2011年に GitHub 社が提唱したシンプルなワークフロー。main ブランチを常にデプロイ可能な状態に保ちます。

main    ─●──●──●──●──●──●──── (常にデプロイ可能)
         │   │     │
feature1 ●─●─●     │
feature2     ●──●──●

ブランチの役割

ブランチ	目的
main	本番リリース版（常にデプロイ可能）
feature/*	新機能・修正

ワークフロー

1. main から新しいブランチを作成
2. コミットして push
3. Pull Request を作成
4. レビュー・CI 実行
5. main にマージ
6. すぐにデプロイ

# ブランチ作成
git checkout -b add-dark-mode

# 開発
git commit -am "ダークモード追加"
git push origin add-dark-mode

# GitHub で PR を作成 → レビュー → マージ

メリット

• シンプルで理解しやすい
• 継続的デプロイに最適
• ブランチ管理が楽

デメリット

• 複数バージョンの並行維持が困難
• 大規模プロジェクトには向かない
• リリースタグ管理が別途必要

Trunk Based Development（TBD）

モダンな開発現場で主流になっているワークフロー。**「長命ブランチを避ける」**のが核心です。

main (trunk) ──●──●──●──●──●──●──●──●──── (統合ブランチ)
               │  │  │  │  │  │  │  │
               ●  ●  ●  ●  ●  ●  ●  ●    (短命ブランチ: 数時間〜1日)

特徴

• 短命ブランチ: 数時間〜1日で main にマージ
• 高頻度マージ: 1日に複数回マージ
• Feature Flag: 未完成機能は本番に含めるが無効化
• CI/CD: 自動テスト必須

ワークフロー

# 朝、main から分岐
git checkout -b fix-login main

# 数時間で開発完了
git commit -am "ログイン修正"

# すぐ main にマージ
git checkout main
git merge fix-login
git push origin main

Feature Flag の活用

未完成機能を main にマージしつつ、本番では無効化します。

if (featureFlags.newDashboard) {
  return <NewDashboard />;
} else {
  return <OldDashboard />;
}

メリット

• コンフリクトが少ない（短命ブランチ）
• CI/CD との相性抜群
• 高速なフィードバックループ
• Google、Facebook、Netflix で実績

デメリット

• 高い自動テストカバレッジが必須
• Feature Flag の管理が必要
• 成熟したチーム文化が必要

ワークフロー選択ガイド

チーム規模別

チーム規模	推奨ワークフロー
1-5人	GitHub Flow
5-15人	GitHub Flow または Trunk Based
15-50人	Trunk Based
50人以上	Trunk Based + Monorepo

プロジェクト特性別

特性	推奨
継続的デプロイ	GitHub Flow / Trunk Based
定期リリース	GitFlow
複数バージョン並行サポート	GitFlow
SaaS 単一バージョン	GitHub Flow / Trunk Based
エンタープライズ	GitFlow
スタートアップ	GitHub Flow
OSS	GitHub Flow

実務で使う Git コマンド集

ブランチ操作

# 新しいブランチを作成して切り替え
git checkout -b feature/new-feature

# ブランチ一覧
git branch         # ローカル
git branch -a      # リモート含む
git branch -r      # リモートのみ

# ブランチ削除
git branch -d feature/old    # マージ済みのみ
git branch -D feature/old    # 強制削除

# リモートブランチ削除
git push origin --delete feature/old

変更の取り込み

# リベース（履歴を綺麗に）
git checkout feature
git rebase main

# マージ（履歴をそのまま）
git merge main

# プル（フェッチ + マージ）
git pull origin main

# プル（フェッチ + リベース）
git pull --rebase origin main

コミット操作

# 直前のコミットを修正
git commit --amend

# 過去のコミットを編集
git rebase -i HEAD~3

# コミットを取り消し（履歴を保持）
git revert HEAD

# コミットを取り消し（履歴を削除）
git reset --hard HEAD~1

stash（一時退避）

# 現在の変更を退避
git stash

# 退避一覧
git stash list

# 復元
git stash pop

# 名前を付けて保存
git stash save "WIP: ログイン修正"

コミットメッセージのベストプラクティス

Conventional Commits

<type>: <description>

[optional body]

[optional footer]

type の例:

type	用途
feat	新機能
fix	バグ修正
docs	ドキュメント
style	フォーマット（ロジック変更なし）
refactor	リファクタリング
perf	パフォーマンス改善
test	テスト追加・修正
build	ビルドシステム
ci	CI/CD
chore	その他の雑務

例:

feat(auth): Google OAuth ログインを追加

- Google OAuth 2.0 プロバイダーの実装
- ユーザー情報の取得とDB保存

Closes #123

Semantic Versioning との連動

Conventional Commits から自動的に SemVer バージョンを算出できます。

• BREAKING CHANGE: → メジャー
• feat: → マイナー
• fix: → パッチ

Pull Request のベストプラクティス

PR のサイズ

小さく保つのが原則です。

サイズ	行数	レビュー効率
理想	<200行	高
許容	200-500行	中
大きすぎ	500行以上	低

PR テンプレート

## 概要
何を・なぜ変更したか

## 変更内容
- 項目1
- 項目2

## テスト方法
1. 手順1
2. 手順2

## スクリーンショット
(UI変更がある場合)

## 関連チケット
Closes #123

チームでの運用 Tips

1. ブランチ保護ルール

GitHub で main ブランチを保護:

• 直接 push を禁止
• PR 経由のみマージ可能
• CI パス必須
• レビュー 1件以上必須

2. コードオーナー

# .github/CODEOWNERS
/src/auth/ @security-team
/src/ui/ @frontend-team
*.md @docs-team

3. 自動化

• Dependabot: 依存関係の自動更新
• GitHub Actions: CI/CD の自動実行
• CODEOWNERS: 自動レビュアー割り当て

まとめ

Git ワークフローに絶対の正解はありません。チームの規模、成熟度、プロジェクト特性に応じて選択しましょう。

推奨の選び方:

1. 小規模・モダンな開発 → GitHub Flow
2. 成熟したチーム・継続的デプロイ → Trunk Based Development
3. エンタープライズ・定期リリース → GitFlow

最も重要なのは「チーム全員が同じルールで運用する」ことです。ワークフローの詳細はドキュメント化し、新メンバーにも共有できるようにしておきましょう。

参考リンク

• A successful Git branching model - Vincent Driessen (GitFlow)
• GitHub Flow 公式ガイド
• Trunk Based Development
• Conventional Commits
• Pro Git Book