Git Ready 3-way マージを避けるブランチ運用
feature ブランチに main を取り込んでから main にマージすることで、不要な 3-way マージを防ぐ方法
3-way マージとは
main と feature の両方にコミットが進んでいると、Git は共通の祖先・main の先端・feature の先端の 3 つのスナップショット を比較してマージします。
これが 3-way マージです。
このとき必ずマージコミットが作られ、コンフリクトが発生するリスクも高くなります。
推奨フロー: feature <- main してから feature -> main
3-way マージを避けるには、main にマージする 前に main の最新を feature に取り込んでおきます。
feature ブランチで main を取り込む
git switch feature/xxx→git merge main（またはgit rebase main）コンフリクトがあればここで解決
feature ブランチ上で解決するので、main は常にクリーンな状態を維持できます。
main に feature をマージ
git switch main→git merge feature/xxxfeature が main の最新を含んでいるため、fast-forward マージになります。履歴を残したい場合は
--no-ffを付けます。
# 1. feature ブランチで main の最新を取り込む
git switch feature/login
git merge main
# コンフリクトがあればここで解決
# 2. main に feature をマージ（fast-forward になる）
git switch main
git merge feature/login
# 履歴を残したい場合
git merge --no-ff feature/loginなぜこの順番がよいのか
| 手順 | feature -> main を直接マージ | feature <- main してから feature -> main |
|---|---|---|
| コンフリクト解決の場所 | main 上（壊れると全員に影響） | feature 上（自分だけで済む） |
| マージの種類 | 3-way マージ（複雑） | fast-forward（単純） |
| main の安定性 | コンフリクト解決ミスが入るリスク | 常にクリーン |
| レビューのしやすさ | マージコミットに差分が混ざる | feature の差分だけが明確 |
チーム開発では「main を壊さない」ことが最優先です。
コンフリクト解決を feature 側で済ませるこのフローが安全です。
補足
GitHub の Pull Request を使う場合も同じ考え方
PR のマージ前に main の最新を feature に取り込んでおくと、PR 上でのコンフリクトを防げます。GitHub の「Update branch」ボタンがこの操作に相当します。
履歴の整理に rebase / cherry-pick は不要
このフローは
mergeだけで完結します。直線的な履歴にこだわる必要はありません。詳しくは きれいな履歴にこだわりすぎない を参照してください。