プルリクエストを出す

push しただけでは、main に入らない

作業ブランチを GitHub へ送っても、その変更は本流には入りません。main は多くのチームで直接触らないよう保護されていて、入れるには「このブランチの変更を main に取り込んでください」と申請する必要があります。これがプルリクエスト (PR) です。Git の機能ではなく GitHub の機能で、マージの前に「見せて、話して、決める」時間を挟むための仕組みです。

作るには、まずブランチを push します。

$ git push -u origin feature/login-form

push すると、ターミナルに PR 作成画面の URL が案内として出ます。ブラウザで開いても、gh コマンドで作っても、できあがるものは同じです。

$ gh pr create --base main --title "ログインフォームを追加" --reviewer taro

--base が取り込み先です。ブラウザで作る場合も、取り込み先と取り込み元が逆になっていないかだけは必ず確かめてください。逆向きにも作れてしまいます。レビュアーの指名は 1〜2 人に絞ります。5 人に頼むと、全員が「他の誰かが見るだろう」と思って誰も見ません。

2,000 行の PR は、誰にも読まれない

プルリクエストで最も差が出るのは、コマンドではなく大きさです。レビューできる差分の量には限界があり、数百行を超えたあたりから、読む側は 1 行ずつ追うのをやめて雰囲気で承認しはじめます。そうなった PR は、通ったように見えて誰も検証していません。

ありがちなのがこの流れです。ログインフォームを作っている途中で既存コードのインデントが気になり、ついでにフォーマッタを全ファイルにかけてしまう。差分は 2,000 行になり、本題の 80 行は書式だけの 1,900 行に埋もれて誰にも読まれません。

混ぜないための対策は、作業を始める前にブランチを分けることです。整形したくなったら、その場でやらずにメモしておき、あとで別ブランチを切ります。タイトルに「と」が 2 回出てきたら、PR を分ける合図です。

説明文にファイル名を並べても、誰も助からない

説明文の目的は、レビュアーが差分を読む前に文脈をそろえることです。コードを見れば分かることは書かず、コードを見ても分からないことを書きます。

## 目的
Issue #142 のログイン画面を実装する

## 変更点
- LoginForm コンポーネントを追加
- 送信処理はまだ未接続（次の PR で対応）

## 確認したこと
- ローカルで /login を開き、送信ボタンの活性状態を確認
- 既存のテストが全て通ることを確認

## 見てほしい点
- 状態管理を useState でやっていますが、他画面に合わせるべきでしょうか

目的、変更点、確認方法、見てほしい点の 4 つです。変更したファイル名の羅列は要りません。それは GitHub が勝手に表示します。

まだ相談したい段階なら gh pr create --draft で Draft として出します。マージボタンが押せず、レビュアーへの通知も飛ばないので、骨組みだけ見せて「この設計で進めていいですか」と聞くのに向いています。完成後に全部書き直す事故を防げます。ただし、終わったのに Draft のまま放置すると誰にも気づかれません。

マージが済んだらリモートのブランチを消し、手元も片付けます。-d はマージ済みのブランチだけを消すので、消し忘れの検出も兼ねます。

$ git switch main
$ git pull
$ git branch -d feature/login-form