フィーチャーブランチとは - 機能ごとに独立したブランチで開発しマージする Git ワークフロー

フィーチャーブランチとは

フィーチャーブランチ (Feature Branch) は、新機能やバグ修正ごとに main から独立したブランチを作成し、開発完了後にプルリクエスト (PR) を経て main にマージする Git ワークフローである。GitHub Flow の基本パターンであり、現代のソフトウェア開発で最も広く採用されている。

main ─────────────────────────────────
       \                    /
        feature/add-auth ──  (PR → レビュー → マージ)

ワークフロー

ワークフローの例を示す。

# 1. main から新しいブランチを作成
git checkout main && git pull
git checkout -b feature/add-auth

# 2. 開発・コミット
git add . && git commit -m "Add authentication middleware"

# 3. リモートにプッシュ
git push -u origin feature/add-auth

# 4. PR を作成 → コードレビュー → マージ
# 5. マージ後、ローカルのブランチを削除
git checkout main && git pull
git branch -d feature/add-auth

メリットとデメリット

メリットとデメリットを以下にまとめる。

メリット	デメリット
未完成のコードが main に入らない	ブランチが長寿命化するとコンフリクト増大
PR でコードレビューが強制される	マージ待ちの PR が溜まると開発速度低下
機能単位でロールバックしやすい	ブランチ間の依存関係が複雑になりうる
CI が各ブランチで独立して実行される	ブランチの乱立で管理が煩雑になる

トランクベース開発との比較

トランクベース開発との主な違いを以下に比較する。

観点	フィーチャーブランチ	トランクベース開発
ブランチ	機能ごとに作成	main に直接コミット
未完成機能	ブランチに隔離	フィーチャーフラグで隠す
レビュー	PR でマージ前にレビュー	ペアプログラミング or 事後レビュー
デプロイ頻度	PR マージ時	コミットごと (1 日複数回)
適するチーム	小〜中規模、非同期レビュー	大規模、高頻度デプロイ

Google や Meta はトランクベース開発を採用している。フィーチャーブランチは小〜中規模チームや、非同期でコードレビューを行うチームに適している。

実務でのベストプラクティス

ブランチの寿命を短く保つ

ブランチの寿命は 1〜3 日以内に抑える。1 週間以上のブランチはコンフリクトの温床になる。大きな機能は小さな PR に分割し、段階的にマージする。

main を頻繁に取り込む

毎日 main をフィーチャーブランチにマージ (またはリベース) して差分を小さく保つ。マージ時のコンフリクトを小さく、頻繁に解決する方が、最後にまとめて解決するより安全だ。

ブランチ命名規則

チームで命名規則を統一する。

feature/add-auth        # 新機能
fix/login-timeout       # バグ修正
refactor/extract-utils  # リファクタリング
chore/update-deps       # 依存関係の更新

マージ後のブランチ削除

マージ済みのブランチは即座に削除する。GitHub の「Auto-delete head branches」設定を有効にすれば自動化できる。

詳しくは関連書籍を参照。