Gitブランチ戦略：rebase vs merge の使い分けとチーム運用

Git FlowからGitHub Flow、トランクベース開発まで、ブランチ戦略の比較とrebase/mergeの使い分けを解説します。

2 min read

はじめに

チーム開発において、Git のブランチ戦略はコードの品質と開発速度を左右する重要な要素です。本記事では、代表的なブランチ戦略を比較し、rebase と merge の使い分けを解説します。

ブランチ戦略の比較

Git Flow

Vincent Driessen が提唱した戦略で、以下のブランチを使い分けます。

ブランチ目的ライフサイクル
mainリリース済みコード永続
develop開発統合ブランチ永続
feature/*新機能開発一時的
release/*リリース準備一時的
hotfix/*緊急修正一時的
# feature ブランチの作成と完了
git checkout -b feature/user-auth develop
# ... 開発 ...
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

適するケース: リリースサイクルが明確なプロダクト、複数バージョンの並行保守

GitHub Flow

main ブランチとフィーチャーブランチのみのシンプルな戦略です。

# 1. main からブランチを作成
git checkout -b feature/add-search main

# 2. コミットしてプッシュ
git add .
git commit -m "feat: add search functionality"
git push -u origin feature/add-search

# 3. Pull Request を作成してレビュー

# 4. main にマージ（PR経由）

# 5. デプロイ

適するケース: 継続的デプロイ、Web アプリケーション、小〜中規模チーム

トランクベース開発

全開発者が main（トランク）に直接コミットまたは短命ブランチで開発します。

# 短命ブランチ（1-2日以内にマージ）
git checkout -b fix/typo main
# ... 修正 ...
git checkout main
git merge fix/typo
git branch -d fix/typo

適するケース: CI/CD が成熟したチーム、フィーチャーフラグを活用する組織

比較表

戦略複雑さリリース管理CI/CD 前提チーム規模
Git Flow高明確不要大
GitHub Flow低シンプル推奨小〜中
トランクベース中継続的必須任意

rebase vs merge

merge（マージコミット）

git checkout main
git merge feature/add-search
  • マージコミットが作成される
  • 分岐と統合の履歴が保持される
  • コンフリクト解決は1回

rebase（リベース）

git checkout feature/add-search
git rebase main
  • コミットが main の先端に再適用される
  • 線形の履歴になる
  • 各コミットでコンフリクト解決が必要な場合がある

使い分けの指針

状況推奨理由
フィーチャーブランチの更新rebase線形な履歴で差分が見やすい
共有ブランチへの統合merge --no-ffマージポイントが明確
プッシュ済みブランチmergerebase は履歴を書き換えるため危険
1人で開発rebase履歴がきれいになる
チームで開発merge or squash安全で理解しやすい

squash merge

フィーチャーブランチの複数コミットを1つにまとめてマージします。

git checkout main
git merge --squash feature/add-search
git commit -m "feat: add search functionality"

GitHub の PR では「Squash and merge」ボタンで実行できます。

コミットメッセージ規約

Conventional Commits

<type>(<scope>): <description>

[optional body]

[optional footer]
type用途
feat新機能
fixバグ修正
docsドキュメント
refactorリファクタリング
testテスト追加
choreビルド・ツール
git commit -m "feat(auth): add OAuth 2.0 login support"
git commit -m "fix(api): handle null response from payment service"

実践的な運用パターン

フィーチャーブランチのワークフロー

# 1. 最新の main を取得
git checkout main
git pull origin main

# 2. フィーチャーブランチを作成
git checkout -b feature/new-api

# 3. 定期的に main の変更を取り込む
git fetch origin
git rebase origin/main

# 4. プッシュ（rebase 後は force-push が必要）
git push -f origin feature/new-api

# 5. PR 作成 → レビュー → マージ

コンフリクト解決

# rebase 中にコンフリクトが発生した場合
git rebase main
# ... コンフリクトを手動で解決 ...
git add <resolved-files>
git rebase --continue

# rebase を中止する場合
git rebase --abort

関連記事

参考文献

  • Driessen, V. (2010). “A successful Git branching model”.
  • GitHub Flow
  • Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate. IT Revolution Press.
  • Conventional Commits

関連記事