IT 技書の森

フィーチャーブランチ

機能ごとに独立したブランチを作成し、完成後にメインブランチにマージする Git ワークフロー

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」設定を有効にすれば自動化できる。

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

関連用語