章: 第4章: チーム開発の実務フロー
なぜ push しただけでは終わらないのか
Gitを学び始めた段階では、push までできれば十分に見えるかもしれません。しかし実務では、push は共有の入口にすぎません。
そこで使われるのがプルリクエストです。
プルリクエストは、あるブランチの変更を別のブランチへ取り込んでほしいと依頼する仕組みです。
単にコードを置くのではなく、「この変更を見てください」「問題なければ取り込んでください」と、レビュー可能な形で差分を提示するのが目的です。
プルリクエストで見られるもの
プルリクエストでは主に次の情報が見られます。
- 何のための変更か
- どのファイルが変わったか
- 差分の中身
- テストや確認内容
- レビューコメントのやり取り
つまり、プルリクエストは「変更内容の窓口」です。チームメンバーはここを見て、変更の妥当性を判断します。
よくある流れ
たとえば feature/login-validation というブランチで作業した場合、流れは次のようになります。
1. 作業ブランチで実装する
2. コミットする
3. git push origin feature/login-validation
4. GitHub などでプルリクエストを作る
5. main へのマージ依頼を出す
このとき大事なのは、差分が読みやすいことです。プルリクエストは「動けばよい提出物」ではなく、他人が理解して判断するための資料でもあります。
プルリクエスト本文に何を書くか
本文が空に近いと、レビューする側は意図を読み取る負荷が上がります。
最低限、次のような情報があると読みやすくなります。
- 何を変更したか
- なぜ変更したか
- どこを確認してほしいか
- 動作確認をどう行ったか
たとえば「ログイン時のメール形式バリデーションを追加」「正常系と異常系を手動確認済み」のように書くだけでも、レビューの質はかなり上がります。
実務で重要な視点
| 悪い状態 | 良い状態 |
| 差分が大きすぎて読みにくい | 1つの目的に絞られている |
| 変更理由が不明 | 目的と背景が書いてある |
| 動作確認が不明 | テストや確認方法が書いてある |
プルリクエストは、コードの提出ではなく、変更を説明する場でもあります。
チェックポイント: プルリクエストは「マージ依頼」であると同時に「レビュー資料」でもある。この2面性を意識しましょう。
まとめ & 次のステップ
- プルリクエストは変更をレビュー可能な形で提示する仕組み
pushは終点ではなく、プルリクエスト作成の前段階- 差分だけでなく、目的や確認内容も重要
- 読みやすいプルリクエストはレビュー効率を大きく上げる
- 実務ではコードそのものと同じくらい説明の質も大事
次回はレビュー指摘への対応と追加コミットを扱います。 プルリクエストを出したあとに何が起きるのかを見ていきましょう。
