サンプルコードで身につける: マージとその後 — 取り込みと後片付けまでが仕事

解説で学んだ概念を、5つの具体例で確認します。素朴な例から実務寄りの例へと進みます。

1マージ前の最終確認 — CIと承認の状態を見る

マージの条件は「CI がすべて緑」と「必要な承認が揃っている」の2つです。gh pr checks と gh pr view で両方をターミナルから確認できます。多くのチームではブランチ保護設定により、条件が揃うまでマージボタン自体が押せません。

# 1. CI の状態を確認(すべて pass になっているか)
gh pr checks
# => build   pass   1m18s
#    test    pass   2m02s
#    lint    pass   0m41s

# 2. レビューの承認状況を確認
gh pr view
# => title:     ユーザー一覧に検索ボックスを追加
#    reviewers: tanaka (Approved)
#    state:     OPEN

# 3. 未解決のレビュースレッドが残っていないかも見ておく
#    (返信していないコメントを残したままマージしない)

# 多くのチームはブランチ保護ルールで
# 「承認1件以上 + CI 緑」を満たすまでマージ不可に設定している

2squashマージ — PRを1コミットにまとめて取り込む

squash マージは、PR 内の細かいコミットを1つにまとめて main に積む方式です。レビュー対応や typo 修正のコミットが main の履歴に残らず、「1 PR = 1 コミット」の読みやすい履歴になります。多くのチームが既定にしている方式です。

# squash マージを実行(リモートブランチの削除も同時に)
gh pr merge --squash --delete-branch

# ── squash マージで起きること ──
#
# PR 内のコミット(作業の過程がそのまま残っている):
#   ・検索ボックスの骨組みを追加
#   ・typo 修正
#   ・レビュー指摘: 変数名を修正
#   ・レビュー指摘: computed に変更
#
#        ↓ squash(1つに押しつぶす)
#
# main に積まれるコミット(1つだけ):
#   ・ユーザー一覧に検索ボックスを追加 (#45)
#
# → main の履歴が「1 PR = 1 コミット」になり、後から読みやすい

3マージ後の後片付け — ブランチ削除と次の準備

マージされたブランチは役目を終えるので、リモートと手元の両方から削除します。そして手元の main を pull で最新にしてから次のブランチを切ります。この後片付けを怠ると、古いブランチが溜まり、古い main から作業を始める事故が起きます。

# ── マージ後の後片付けルーティン ──

# 1. main に切り替えて最新を取り込む(マージされた自分の変更が入る)
git switch main
git pull

# 2. 役目を終えた手元のブランチを削除
git branch -d feature/user-search
#   ※ リモート側は gh pr merge --delete-branch や
#     GitHub の自動削除設定で消えていることが多い

# 3. リモートで消えたブランチの残骸を手元からも掃除
git fetch --prune

# 4. 最新の main から次の作業ブランチを切る
git switch -c feature/next-work

# この 1〜4 を毎回のマージ後に回すのが日々のリズムになる

4コンフリクトが出たら — mainを取り込んで解消する

他の PR が先にマージされ、自分の PR と同じ箇所を変更していると、マージできない(コンフリクト)状態になります。基本手順は、最新の main を自分のブランチに取り込み、衝突箇所を手で直してコミットし、push するだけです。

# PR 画面に「This branch has conflicts」と出たときの基本手順

# 1. 最新の main を取得して、自分のブランチに取り込む
git fetch origin
git switch feature/user-search
git merge origin/main
# => CONFLICT (content): Merge conflict in src/app/user-list/user-list.ts

# 2. 衝突したファイルを開くと、両方の変更が印付きで並んでいる
#    <<<<<<< HEAD          … 自分のブランチの内容
#    =======
#    >>>>>>> origin/main   … main 側の内容
#    → 印を消しながら「正しい最終形」に手で直す

# 3. 直したファイルをコミットして push すれば PR も解消される
git add src/app/user-list/user-list.ts
git commit    # マージコミットのメッセージは既定のままでよい
git push

5マージ方式は3種類 — チームの既定に従う

GitHub のマージには merge commit・squash・rebase の3方式があり、main の履歴の残り方が変わります。どれを使うかはリポジトリ設定でチームが決めていることが多いので、まず自チームの既定を確認しましょう。

# ── GitHub の3つのマージ方式と履歴の残り方 ──

# 1. merge commit(gh pr merge --merge)
#    PR の全コミット + マージコミットがそのまま main に残る
#    → 作業過程を全部残したいチーム向け。履歴は枝分かれして複雑

# 2. squash(gh pr merge --squash)
#    PR 全体を1コミットに押しつぶして main に積む
#    → 「1 PR = 1 コミット」で履歴が一直線。採用チームが多い

# 3. rebase(gh pr merge --rebase)
#    PR の各コミットを main の先頭に並べ直して積む
#    → コミット単位の履歴を残しつつ一直線にしたいチーム向け

# どの方式が使えるかはリポジトリの Settings で制限されている
# ことが多い。迷ったらチームの既定・慣習に従うのが正解