長期ブランチの安全なマージ戦略

feature ブランチが長期間 main から離れると、どこで競合が起きるか予測しにくくなります。「マージしてみたら大量のコンフリクト」という事態を避けるには、マージ前の事前調査が不可欠です。

この記事では git diff を使った競合リスクの事前特定から、隔離ブランチでの安全な統合、統合後の検証までを段階的に解説します。

ステップ 1: ファイルレベルの差分調査

まず変更されたファイルの全体像を把握します。

# ブランチ間で追加・変更・削除されたファイルの一覧を取得
git diff --name-status main <feature-branch>

出力例:

A       src/components/NewFeature.tsx
M       src/utils/config.ts
D       src/legacy/old-module.ts

A（追加）・M（変更）・D（削除）のステータスから、影響範囲を一目で把握できます。

影響が大きそうなディレクトリを特定したら、範囲を絞って詳細を確認します。

# 特定ディレクトリに限定して差分を確認
git diff main <feature-branch> -- src/components/

ブランチ側で新規作成されたファイルは git show で内容を確認します。

git show <feature-branch>:src/components/NewFeature.tsx

main 側でも同名・類似ファイルが作られていないか確認し、命名衝突や機能重複を検知します。

調査結果を以下の 3 観点で整理すると、マージ方針を判断しやすくなります。

main に直接マージせず、マージ専用の隔離ブランチで作業します。万一問題が起きても main を汚しません。

git checkout main
git pull origin main
git checkout -b merge/<feature-name>

git merge origin/<feature-branch>

競合が発生した場合はこのブランチ上で解消し、解消内容をコミットします。

マージ完了後、以下を確認します。

# ビルドが通ることを確認
npm run build  # または pnpm build

# テストが通ることを確認
npm test

# 意図しないファイルが混入していないか確認
git diff --stat main

問題がなければ PR を作成し、レビューを経て main に統合します。

あるプロジェクトで、品質評価ループを実装した feature ブランチが 2 週間 main から離れた状態になりました。その間に main 側では同じディレクトリに別の評価基準ファイルが追加されていました。

git diff --name-status で調査した結果、ファイル名の衝突はなく、用途も異なることが判明。隔離ブランチでマージを実行し、競合ゼロで統合が完了しました。事前調査に約 1 時間、マージ実行は 15 分で済み、リグレッションも発生しませんでした。

Feature Branch Workflow のベストプラクティスでは、ブランチの寿命を短く保つことが推奨されています。以下のコマンドで未マージブランチを定期的に棚卸しできます。

# リモートの未マージブランチを最終コミット日付順に一覧
git for-each-ref --sort=committerdate --format='%(refname:short) %(committerdate:relative)' refs/remotes