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

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

フィーチャーブランチ (Feature Branch) は、新機能やバグ修正ごとに main から独立したブランチを作成し、開発完了後にプルリクエスト (PR) を経て main にマージする Git ワークフローである。GitHub Flow が示す基本パターンで、PR を前提とするホスティングサービスの普及とともに、多くのチームで標準的な進め方として使われている。

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 に直接コミット、または 1〜2 日で消す短命ブランチ
未完成機能	ブランチに隔離	フィーチャーフラグで隠す
レビュー	PR でマージ前にレビュー	ペアプログラミング or 事後レビュー
デプロイ頻度	PR マージ時	コミットごと (1 日複数回)
適するチーム	小〜中規模、非同期レビュー	大規模、高頻度デプロイ

Google や Meta (旧 Facebook) は、大規模な組織でトランクベース開発を実践している。

ただし、この二つは排他的な選択ではない。トランクベース開発が禁じているのは長寿命ブランチであって、ブランチそのものではない。提唱者の解説では、main へ直接コミットする形が成立するのは 15 人程度までで、16 人以上のチームでは短命ブランチと PR を組み合わせる方が生産的とされる。そこでも寿命の上限は 2 日で、それを超えたブランチは長寿命ブランチに転落したとみなす。

つまり実際の分岐点は、ブランチを作るかどうかではなく、ブランチが何日生きるかである。フィーチャーブランチ運用でも寿命を 1〜2 日に抑え、未完成の機能をフィーチャーフラグで隠せば、トランクベース開発とほぼ同じ状態になる。フィーチャーブランチが特に向くのは、レビューを非同期で回すチームである。

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

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

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

main を頻繁に取り込む

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

ブランチ命名規則

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

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

マージ後のブランチ削除

マージ済みのブランチは即座に削除する。GitHub ならリポジトリの Settings の General にある Pull Requests 欄で「Automatically delete head branches」を有効にすれば、マージと同時に削除される (2026 年 8 月時点の設定名)。

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