サンプルコードで身につける: プルリクエストとは — 差分を取り込んでもらう依頼

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

1pushしただけではmainは変わらない

作業ブランチを push しても、それはリモートにブランチのコピーができただけです。main に反映するには PR を作ってマージしてもらう必要があります。この「push とマージは別物」という区別が PR 理解の出発点です。

# 作業ブランチをリモートに push する
git push -u origin feature/user-card

# この時点のリモートの状態:
#   main                 …… 何も変わっていない
#   feature/user-card    …… 自分の変更が置かれただけ

# main に取り込んでもらうには、ここから PR を作る必要がある。
# push は「荷物を送った」だけ、PR が「受け取りの手続き」

2gh pr create でPRを作る

GitHub の公式 CLI である gh を使うと、ターミナルから PR を作れます。ブラウザで「Compare & pull request」ボタンを押すのと同じ操作です。タイトルと説明文はこの時点で必ず書きます。

# 現在のブランチから main への PR を作成する
gh pr create \
  --title "ユーザーカードの表示を追加" \
  --body "一覧画面にユーザーカードを表示します。チケット #123"

# => https://github.com/my-team/my-app/pull/45 のような URL が発行される

# 作った PR をブラウザで開く
gh pr view --web

# ブラウザ派なら: push 直後にリポジトリ画面へ行くと
# 「Compare & pull request」ボタンが出るので、それを押してもよい

3PRで走る2つのチェック — レビューとCI

PR を作ると、人間によるコードレビューと機械による CI の2つのチェックが動きます。どちらも「main に悪いコードを入れない」ための関所です。両方をパスして初めてマージできる設定にしているチームがほとんどです。

# ── PR という関所で走る2つのチェック ──

# チェック1: CI(自動)
#   PR の作成や push をきっかけに、GitHub Actions などが
#   テスト・ビルド・Lint を自動実行する
gh pr checks
# => build   pass   1m20s
#    test    pass   2m05s
#    lint    fail   0m45s   ← 赤があるうちはマージできない

# チェック2: コードレビュー(人間)
#   チームメンバーが差分を読み、コメントや承認(Approve)を付ける
gh pr view
# => Reviewers: tanaka (Approved), suzuki (Requested)

# 「CI が全部緑」+「必要な承認が揃う」の両方でマージ可能になる

4PRの一生 — オープンからマージまで

PR には作成からマージまでの決まった流れがあります。レビューで指摘があれば修正の push を繰り返し、承認と CI が揃ったらマージしてクローズです。この一連の流れを頭に入れておくと、いま自分がどの段階にいるか迷わなくなります。

# ── PR の一生 ──
#
# 1. オープン     : gh pr create で PR を作る
#        ↓
# 2. レビュー中   : レビュアーがコメント、CI が自動実行
#        ↓
# 3. 修正対応     : 指摘に沿って直し、同じブランチに push
#                   (push した分は自動で PR に追加される)
#        ↓ 2〜3 を必要なだけ繰り返す
# 4. 承認         : レビュアーが Approve、CI が全部緑
#        ↓
# 5. マージ       : main に取り込まれ、PR はクローズされる

# 自分の PR がいまどの段階かは gh pr status で確認できる
gh pr status

5ブランチへの追加pushはPRに自動反映される

PR は「ブランチ同士の差分」を見せる画面なので、PR を出したあとに同じブランチへ push すると、その分も自動的に PR の差分へ追加されます。レビュー対応のたびに PR を作り直す必要はありません。

# PR は「feature/user-card と main の差分」を映す窓のようなもの

# PR を出したあとにレビュー指摘を受けて修正した場合
git add src/app/user-card/user-card.ts
git commit -m "レビュー指摘: 変数名を分かりやすく修正"

# 同じブランチに push するだけでよい
git push

# => 追加のコミットが既存の PR に自動で反映される。
#    新しい PR を作り直す必要はない。
#    CI もこの push をきっかけに再実行される