フレームワーク活用ガイドひとことで言うと#
新しい機能やバグ修正ごとにメインブランチから短命なブランチを切り、作業が完了したらプルリクエストを経てマージするというシンプルなGit運用戦略。
押さえておきたい用語#
- フィーチャーブランチ（Feature Branch）
- 1つの機能やバグ修正のためにメインブランチから分岐した短命なブランチのこと。作業完了後にPRを経てマージし、速やかに削除する。
- ブランチプロテクション（Branch Protection）
- メインブランチへの直接pushを技術的に禁止する設定のこと。PR経由のマージのみを許可し、CIの成功やレビュー承認を必須条件にできる。
- スカッシュマージ（Squash Merge）
- フィーチャーブランチの複数コミットを1つのコミットにまとめてマージする手法のこと。メインブランチの履歴が「1機能1コミット」でクリーンに保たれる。
- コンフリクト（Conflict）
- 複数のブランチが同じファイルの同じ箇所を変更した場合に発生するマージの競合のこと。ブランチが長寿命になるほどリスクが増大する。
フィーチャーブランチ戦略の全体像#
こんな悩みに効く#
- メインブランチに直接コミットしていて、壊れた状態がそのまま共有される
- 複数の機能を並行開発したいが、変更が混ざって混乱する
- コードレビューの仕組みがなく、品質にばらつきがある
基本の使い方#
チームで統一した命名規則を設定する。
feature/ユーザー認証機能やfeature/TICKET-123-add-login- バグ修正は
fix/、リファクタリングはrefactor/などプレフィックスで区別 - チケット番号を含めると、ブランチとタスクの紐付けが容易になる
ポイント: 命名規則はシンプルに保つ。複雑すぎると守られなくなる。
作業開始時にメインブランチの最新を取得してからブランチを作成する。
git checkout main && git pull && git checkout -b feature/my-feature- 作業中もメインブランチの変更を定期的に取り込む（rebaseまたはmerge）
- ブランチの寿命は短く保つ（理想は数日以内）
ポイント: 長寿命ブランチはコンフリクトの温床。小さく分割して早くマージする。
作業が完了したらプルリクエスト（PR）を作成し、チームメンバーにレビューを依頼する。
- PRの説明に変更の目的、影響範囲、テスト方法を記載する
- CIで自動テスト・静的解析を実行し、合格を必須にする
- 最低1名の承認を得てからマージする
ポイント: PRは小さく保つ。変更行数が多いPRはレビューの質が下がる。目安は300行以内。
マージが完了したら不要になったブランチを速やかに削除する。
- GitHubの「自動削除」設定を有効にする
- 定期的にリモートの古いブランチを棚卸しする
- マージ戦略（merge commit / squash merge / rebase merge）をチームで統一する
ポイント: squash mergeを使うと、1機能1コミットでメインブランチの履歴がクリーンに保たれる。
具体例#
命名規則: feature/JIRA-XXX-簡潔な説明（例: feature/APP-42-user-profile）
フロー: Jiraチケットを「作業中」に移動 → mainの最新からブランチ作成 → こまめにコミット → PR作成（テンプレートに沿って説明記入） → CI通過 + 1名以上の承認 → squash mergeでマージ → ブランチ自動削除
ルール: PRは原則300行以下。メインブランチへの直接pushはBranch Protectionで禁止。ブランチ寿命は最長5営業日。
結果: メインブランチが常にデプロイ可能な状態を維持。コードレビューが定着し、バグの早期発見が月平均8件増加。
Before: 大機能を2週間かけて1つのフィーチャーブランチで開発。マージ時に47ファイルのコンフリクトが発生し、解消に丸1日かかった。解消ミスでバグが3件混入。
改善: 大機能を5つの小さなPRに分割。各PRは2〜3日で完了し、200行以内。
After: コンフリクトの発生が47ファイル→平均2ファイル。解消時間は丸1日→15分。バグの混入もゼロに。
設定:
- Branch Protection: mainへの直接push禁止、CI合格必須、最低1名のApprove必須
- CODEOWNERS:
/src/auth/*→@security-team、/src/payment/*→@fintech-team - PR Template: 変更理由・影響範囲・テスト方法を必須項目に
結果: セキュリティ関連のコードは必ずセキュリティチームがレビュー。ルールの属人化が解消され、「うっかりmainに直pushして壊す」事故が年12件→0件に。
やりがちな失敗パターン#
- ブランチを長期間放置する — 1週間以上マージされないブランチはコンフリクトのリスクが急増する。機能を小さく分割し、頻繁にマージする
- PRのサイズが大きすぎる — 1,000行超のPRはレビュアーが細部を見落とす。1PRあたり300行以内を目安に分割する
- メインブランチの保護設定をしない — ルールがあっても、技術的に直接pushできる状態だと事故が起きる。Branch Protectionを必ず設定する
- マージ戦略がチーム内でバラバラ — merge commitとsquash mergeが混在すると履歴が読みにくくなる。チームで1つのマージ戦略に統一する
まとめ#
フィーチャーブランチ戦略は、チーム開発におけるGit運用の基本形。機能ごとの独立したブランチ、プルリクエストによるレビュー、CIによる自動検証の3つを組み合わせることで、メインブランチの品質を保ちつつ並行開発を実現する。シンプルだからこそ確実に運用し、ブランチの短命化とPRの小型化を心がけよう。