タイトル: ブランチのマージと削除
SEOタイトル: Git ブランチのマージと削除完全ガイド
| この記事の要点 |
|
マージの基本フロー
feature ブランチで作業した変更を main に取り込み、不要になったブランチを削除するのが日常作業です。
# 1. main を最新化
git checkout main
git pull origin main
# 2. feature を main にマージ
git merge feature
# 3. リモートに反映
git push origin main
# 4. ローカルブランチを削除
git branch -d feature
# 5. リモートブランチを削除
git push origin --delete featureFast-Forward マージと 3-Way マージ
Git のマージには 2 種類あります。違いを理解すると履歴が読みやすくなります。
| 種類 | 条件 | 結果 |
|---|---|---|
| Fast-Forward | 分岐後に取り込み先が進んでいない | HEAD が前進するだけ。マージコミット無し |
| 3-Way Merge | 両者が進んでいる | 共通祖先 + 両側の3点を合成したマージコミットが作られる |
[Fast-Forward の例]
main: A---B
feature: \---C---D
↓ git merge feature
main: A---B---C---D （feature と同じ位置に進むだけ）
[3-Way Merge の例]
main: A---B---E---F
feature: \---C---D
↓ git merge feature
main: A---B---E---F---M （M がマージコミット、親が F と D の2つ）
\---C---D---/--no-ff: マージコミットを強制する
Fast-Forward 可能でも、「ここで feature をマージした」という履歴を残したい場合は --no-ff を使います。GitHub Flow / GitLab Flow 推奨パターン。
# Fast-Forward 可能でもマージコミットを作る
git merge --no-ff feature -m "Merge feature/login into main"
# 履歴がブランチ構造のまま残る
git log --graph --oneline --all--squash: 複数コミットを1つにまとめる
feature ブランチに「WIP」「typo fix」など細かいコミットが残っている場合、main に取り込む際に1つにまとめる戦略です。
# feature の全変更を main のステージに展開（コミットはまだ）
git checkout main
git merge --squash feature
# 自分でコミットメッセージを書いてコミット
git commit -m "feat(login): add login feature"
# feature ブランチの履歴は main には残らない
# → feature ブランチを削除する
git branch -D featureコンフリクト解決
両者が同じファイルの同じ行を変更していると、自動マージできずコンフリクトになります。
$ git merge feature
Auto-merging src/Login.php
CONFLICT (content): Merge conflict in src/Login.php
Automatic merge failed; fix conflicts and then commit the result.
# ファイルを開くと
<<<<<<< HEAD
$user = User::find($id);
=======
$user = User::findOrFail($id);
>>>>>>> feature# 1. ファイルを編集してマーカーを削除、正しい状態にする
vim src/Login.php
# 2. 解決済としてステージ
git add src/Login.php
# 3. マージコミット作成
git commit
# やり直す場合
git merge --abort
# 状況確認
git status
git diff --check # 残ったマーカーを検出ブランチの削除
| コマンド | 動作 |
|---|---|
git branch -d feature | マージ済の場合のみ削除（安全） |
git branch -D feature | 未マージでも強制削除（危険） |
git push origin --delete feature | リモートブランチ削除 |
git push origin :feature | ↑と同じ（古い書き方） |
git fetch --prune | リモートで消えたブランチをローカル参照から削除 |
git branch --merged main | main にマージ済のブランチ一覧 |
# マージ済の不要ブランチを一括削除
git branch --merged main | grep -v "main\|develop" | xargs git branch -d
# リモート追跡参照の整理
git remote prune origin
# または
git fetch --pruneSquash merge / Rebase merge / Merge commit の比較
GitHub の Pull Request 設定でどれを許可するか選べます。チーム方針で統一しましょう。
| 戦略 | 履歴 | 長所 | 短所 |
|---|---|---|---|
| Merge commit | 分岐の形が残る | いつどの PR をマージしたか明確 | 履歴が複雑 |
| Squash merge | 1 PR = 1 コミット（直線） | main がクリーン。リバートが簡単 | 細かい途中コミットは消える |
| Rebase merge | 個別コミットが直線に並ぶ | 履歴が直線で読みやすい | force push が必要なケース有 |
GitHub PR 設定での切替
Settings → General → Pull Requests:
- Allow merge commits（マージコミット作成）
- Allow squash merging（推奨デフォルト、main の履歴がきれい）
- Allow rebase merging（履歴を直線に保ちたい場合）
- Automatically delete head branches を ON にすると PR マージ時に feature ブランチが自動削除されて運用が楽
FAQ
Q: -d で「not fully merged」と言われて削除できない
A: そのブランチの変更が main に取り込まれていません。マージ済か確認するか、本当に捨てて良いなら -D で強制削除。
Q: 削除したブランチを復活させたい
A: git reflog で削除前の SHA を探し、git branch feature <sha> で復元。
Q: Squash merge した場合、feature ブランチは -d で消せる？
A: Git 的には「マージされた」と認識されないので -D が必要です。GitHub PR の Squash merge も同様。