← GitHubに戻る

Git ブランチ戦略完全ガイド - Git Flow、GitHub Flow、トランクベース

📅 2025-07-01
Git ブランチ戦略 Git Flow GitHub Flow

ブランチ戦略とは

ブランチ戦略は、複数人でのGit運用ルールを定めたものです。

なぜブランチ戦略が必要か

  • 🔀 複数の機能を並行開発
  • 🐛 本番コードを壊さずにバグ修正
  • 👥 チームメンバー間の衝突を防ぐ
  • 📦 リリースを計画的に管理
  • 🔄 緊急対応（ホットフィックス）を迅速に

主要なブランチ戦略

1. Git Flow（複雑だが堅牢）

ブランチ構成

  • main: 本番環境のコード
  • develop: 開発の中心
  • feature/*: 新機能開発
  • release/*: リリース準備
  • hotfix/*: 緊急修正

ワークフロー

1. developから feature/new-login を作成
2. 機能開発
3. developにマージ
4. リリース時、release/v1.2.0 を作成
5. テスト・バグ修正
6. mainとdevelopにマージ
7. タグ付け（v1.2.0）

メリット

  • ✅ 明確な役割分担
  • ✅ 複数バージョンの並行管理
  • ✅ リリースプロセスが体系的

デメリット

  • ⚠️ 複雑で学習コストが高い
  • ⚠️ ブランチが多くなる
  • ⚠️ 小規模チームには過剰

2. GitHub Flow（シンプル）

ブランチ構成

  • main: 常にデプロイ可能な状態
  • feature/*: 機能・修正ブランチ

ワークフロー

1. mainから feature/add-button を作成
2. 開発してコミット
3. Pull Requestを作成
4. レビュー・承認
5. mainにマージ
6. 自動デプロイ

メリット

  • ✅ シンプルで分かりやすい
  • ✅ CI/CDと相性が良い
  • ✅ 継続的デプロイに最適

デメリット

  • ⚠️ 計画的リリースには不向き
  • ⚠️ 複数バージョン管理が難しい

3. Trunk-Based Development

特徴

  • main（trunk）ブランチのみ使用
  • フィーチャーフラグで機能を制御
  • 1日に複数回マージ

メリット

  • ✅ マージ競合が最小限
  • ✅ 継続的インテグレーション
  • ✅ シンプル

デメリット

  • ⚠️ 高度なCI/CDが必須
  • ⚠️ 未完成コードの管理が必要

実践: GitHub Flowの使い方

ステップ1: 新機能ブランチ作成

# mainブランチを最新に
git checkout main
git pull origin main

# 新しいブランチを作成
git checkout -b feature/user-profile

# ブランチ名の推奨形式
feature/機能名
fix/バグ名
hotfix/緊急修正名
refactor/リファクタリング内容

ステップ2: 開発とコミット

# ファイルを編集
vim profile.js

# 変更を確認
git status
git diff

# ステージング
git add profile.js

# コミット（分かりやすいメッセージ）
git commit -m "Add user profile page with avatar upload"

# 複数の小さいコミット推奨
git commit -m "Add profile model"
git commit -m "Add profile view"
git commit -m "Add profile controller"

ステップ3: プッシュとPull Request

# リモートにプッシュ
git push origin feature/user-profile

# GitHubでPull Requestを作成
1. GitHubリポジトリを開く
2. 「Compare & pull request」ボタンをクリック
3. タイトルと説明を記入
4. レビュアーを指定
5. 「Create pull request」

ステップ4: コードレビュー

# レビューコメントに対応
1. 指摘箇所を修正
2. コミット
3. プッシュ（自動的にPRに反映）

git add .
git commit -m "Fix: Handle null avatar case"
git push origin feature/user-profile

ステップ5: マージ

# GitHub上で
1. レビュー承認後
2. 「Merge pull request」
3. 「Confirm merge」
4. ブランチ削除（オプション）

# ローカルで最新を取得
git checkout main
git pull origin main

# 不要なブランチを削除
git branch -d feature/user-profile

ブランチ操作コマンド

ブランチの作成と切り替え

# ブランチ作成
git branch feature/new-feature

# ブランチ切り替え
git checkout feature/new-feature

# 作成と切り替えを同時に
git checkout -b feature/new-feature

# または（新しい書き方）
git switch -c feature/new-feature

ブランチ一覧

# ローカルブランチ一覧
git branch

# リモートブランチも表示
git branch -a

# 最終コミット日時も表示
git branch -v

ブランチの削除

# ローカルブランチ削除
git branch -d feature/old-feature

# 強制削除（マージされていなくても）
git branch -D feature/old-feature

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

ブランチのリネーム

# 現在のブランチをリネーム
git branch -m new-branch-name

# 他のブランチをリネーム
git branch -m old-name new-name

マージ戦略

1. Merge Commit（デフォルト）

git checkout main
git merge feature/new-feature

# マージコミットが作成される
# 履歴が完全に保持される

2. Squash Merge

git merge --squash feature/new-feature
git commit -m "Add new feature"

# 複数のコミットを1つにまとめる
# mainブランチがクリーンに保たれる

3. Rebase

git checkout feature/new-feature
git rebase main

# コミット履歴が一直線になる
# マージコミットが不要

どれを選ぶか

  • Merge Commit: 履歴を完全に保持したい
  • Squash Merge: mainをクリーンに（GitHub推奨）
  • Rebase: 一直線の履歴が好み

コンフリクト（衝突）の解決

コンフリクトが発生した時

git merge feature/new-feature
# CONFLICT (content): Merge conflict in app.js

解決手順

1. コンフリクトファイルを開く

<<<<<<< HEAD
const version = '1.0.0';
=======
const version = '2.0.0';
>>>>>>> feature/new-feature

2. 正しいコードに修正
const version = '2.0.0';

3. マーカーを削除

4. ステージング
git add app.js

5. コミット
git commit -m "Resolve merge conflict in app.js"

VS Codeでの解決

VS Codeがコンフリクトを自動検出

「Accept Current Change」: HEADの変更を採用
「Accept Incoming Change」: マージ元を採用
「Accept Both Changes」: 両方を保持
「Compare Changes」: 詳細比較

保護ブランチの設定

GitHubでの設定

Settings > Branches > Add rule

Branch name pattern: main

✅ Require pull request reviews before merging
  - Required approvals: 1
✅ Require status checks to pass before merging
✅ Require branches to be up to date before merging
✅ Include administrators

効果

  • mainへの直接プッシュを禁止
  • レビュー必須
  • CI/CDテスト必須

実用的なTips

Tip 1: コミットメッセージ規約

feat: 新機能
fix: バグ修正
docs: ドキュメント変更
style: コード整形
refactor: リファクタリング
test: テスト追加
chore: ビルド・ツール変更

例:
feat: Add user authentication
fix: Fix null pointer in login
docs: Update API documentation

Tip 2: PRテンプレート

# .github/pull_request_template.md

## 変更内容
- 

## テスト方法
1. 

## スクリーンショット

## チェックリスト
- [ ] テストを追加した
- [ ] ドキュメントを更新した
- [ ] コードレビュー可能

Tip 3: 定期的なmainとの同期

# feature開発中、mainの最新を取り込む
git checkout main
git pull origin main
git checkout feature/my-feature
git merge main

# または rebase
git rebase main

チーム別の推奨戦略

小規模チーム（1-5人）

  • ✅ GitHub Flow
  • シンプルで管理が楽
  • 継続的デプロイ

中規模チーム（6-20人）

  • ✅ GitHub Flow + リリースブランチ
  • 計画的リリース
  • ホットフィックス対応

大規模チーム（21人以上）

  • ✅ Git Flow
  • 複数バージョン管理
  • 厳格なリリース管理

まとめ

適切なブランチ戦略でチーム開発を効率化できます。

重要ポイント

  • プロジェクトに合った戦略を選ぶ
  • mainは常にデプロイ可能に保つ
  • 小さく頻繁にマージ
  • Pull Requestでコードレビュー
  • コンフリクトは早期に解決

次のステップ

  • GitHub ActionsでCI/CD構築
  • Semantic Versioningの理解
  • Git HooksでQA自動化