- Pull Requestって何？一言でいうと「この変更、main に入れていいか一緒に確認してもらうための“申請書”」
- まずは流れをイメージ：Pythonコードをちょっと直してPRを出す
- 重要ポイント1：PRは「コードを見せて相談する場所」であって、単なるマージボタンではない
- 重要ポイント2：PRとCI（自動テスト）をセットで考える
- 重要ポイント3：PRを小さく保つことが、レビューと品質のカギ
- 重要ポイント4：PRは「履歴」としても強力なドキュメントになる
- 例題：実際のPRのイメージ（Pythonプロジェクト）
- 概要
- テスト
- 初心者がPull Requestに慣れるためのステップ
- まとめ（Pull Requestは「main に入れる前に、機械と人間でちゃんと確認するための窓口」）
Pull Requestって何？一言でいうと「この変更、main に入れていいか一緒に確認してもらうための“申請書”」
Pull Request（PR）は、
「自分がブランチで作った変更を、main（や他のブランチ）に取り込んでいいか、レビューとテストを通して確認してもらうための仕組み」です。
Git の世界では「ブランチをマージする」だけならコマンドでできますが、
チーム開発や本番運用では、
どんな変更なのか
テストは通っているのか
設計や命名は妥当か
を確認せずに main に混ぜるのは危険です。
Pull Request は、その「確認の場」を GitHub 上に作るものだと思ってください。
まずは流れをイメージ：Pythonコードをちょっと直してPRを出す
例：add(a, b) 関数にバグがあって、それを直す
例えば、こんなコードが src/math_utils.py にあるとします。
def add(a: int, b: int) -> int:
return a - b # 本当は + にしたいのにバグっている
テストはこう。
def test_add():
assert add(1, 2) == 3
このバグを直すとき、GitHub Flow ならこう動きます。
main を最新にする
ブランチを切る（例：fix/add-function-bug）
コードとテストを直す
ローカルで pytest を回す
GitHub に push する
Pull Request を作る
CI がテストを自動で回す
レビューしてもらう
OKなら main にマージ
この「main に入れる前のワンクッション」が Pull Request です。
重要ポイント1：PRは「コードを見せて相談する場所」であって、単なるマージボタンではない
PRの中身に書くべきこと
PR を作るとき、タイトルと本文を書きます。
タイトル例：Fix bug in add function
本文には、最低限こんなことを書きます。
何を直したか（機能・バグの内容）
なぜそう直したか（意図・背景）
テストはどうしたか（どのテストを追加・修正したか）
例えば：
add 関数が引き算になっていたバグを修正しました。
addをa + bに修正test_addを追加して、1 + 2 = 3 を確認ローカルで
pytest済みです。
こう書いておくと、レビューする人は、
どこを見ればいいか
何を確認すればいいか
がすぐ分かります。
PR は「コードだけ投げる場所」ではなく、
「変更の意図ごと共有する場所」です。
PRで会話することで設計が良くなる
PR では、レビューコメントを通じて会話ができます。
「この名前、もう少し意味が分かるようにできない？」
「この処理、テストケースをもう1つ足した方がよさそう」
「ここ、例外処理が抜けてない？」
こういうやりとりを通して、
コードの質だけでなく、設計や考え方も育っていきます。
PR を「怒られる場所」と捉えるとしんどいですが、
「一緒にコードを良くする場所」と捉えると、かなり心強い仕組みになります。
重要ポイント2：PRとCI（自動テスト）をセットで考える
PRを作った瞬間にテストが自動で走る世界
GitHub Actions で CI を設定しておくと、
PR を作ったタイミングで自動的にテストが走ります。
例えば、こんな ci.yml があるとします。
name: CI
on:
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install -U pip
- run: pip install -e .[dev]
- run: pytest
これがあると、
PRを作る
GitHub Actions が勝手に pytest を実行
テストが通れば「緑」、落ちれば「赤」
という状態になります。
「テストが赤のPRはマージしない」というルール
Pull Request の品質を守るために、
よくこういうルールを決めます。
テストが通っていないPRはマージしないmain にマージするには CI 成功が必須
GitHub のブランチ保護ルールで、
「このブランチにマージするには、このチェック（CI）が成功していること」
を必須にできます。
これにより、
テストが落ちているコードが main に混ざる
→ 本番に出て壊れる
という事故をかなり防げます。
PR は「人間のレビュー」と「機械のチェック（CI）」を
両方通過した変更だけを main に入れるためのゲート、というイメージです。
重要ポイント3：PRを小さく保つことが、レビューと品質のカギ
悪い例：1PRで何でもかんでもやる
初心者がやりがちなのは、
機能追加
リファクタリング
フォーマット修正
設定変更
を全部1つのPRに詰め込んでしまうことです。
こうなると、
レビューが大変
どの変更が原因でバグったか分からない
「とりあえずマージしちゃえ」となりがち
で、品質が一気に落ちます。
良い方向性：1PR = 1つの目的
Pull Request は、できるだけ「目的ごと」に分けます。
バグ修正だけのPR
小さな機能追加だけのPR
リファクタリングだけのPR
例えば、
Fix add function bugAdd /hello endpointRefactor user service
のように、「このPRは何をするためのものか」が一言で言える状態が理想です。
PRが小さいと、
レビューしやすい
テストもしやすい
問題が起きたときに原因を特定しやすい
というメリットがあります。
重要ポイント4：PRは「履歴」としても強力なドキュメントになる
「この変更、なんでこうなってるんだっけ？」に答えてくれる
開発を続けていると、
数ヶ月後・数年後にこういう疑問が出てきます。
「なんでこの関数、こんな仕様なんだっけ？」
「このバグ修正、どういう経緯で入ったんだっけ？」
そのときに役立つのが、過去の Pull Request です。
PR には、
変更内容
議論の履歴（コメント）
テストの状況
レビューでの指摘
が全部残っています。
「この仕様は、当時こういう議論の結果こうなったんだな」
と後から辿れるのは、
設計や運用を続けていくうえでかなり大きな価値があります。
コミットメッセージだけでは足りない部分を補ってくれる
コミットメッセージは短くなりがちですが、
PR の本文やコメントには、もっと文脈を書けます。
「このAPIは将来こう拡張する予定なので、今はこうしておく」
「この実装は暫定で、後でリファクタリングする前提」
といった「背景情報」を残しておくと、
未来の自分やチームメイトがかなり助かります。
例題：実際のPRのイメージ（Pythonプロジェクト）
変更内容
add(a, b) のバグ修正とテスト追加。
src/math_utils.py:
def add(a: int, b: int) -> int:
return a + b
tests/test_math_utils.py:
from math_utils import add
def test_add():
assert add(1, 2) == 3
assert add(-1, 1) == 0
PRのタイトルと本文例
タイトル：Fix add function and add tests
本文：
概要
add関数が引き算になっていたバグを修正しましたtest_addを追加し、正と負のケースをカバーしましたテスト
- ローカルで
pytest実行済み- GitHub Actions の CI も通過しています
これくらい書いておくと、
レビューする人はすぐに状況を理解できます。
初心者がPull Requestに慣れるためのステップ
ステップ1：main に直接 push するのをやめて、必ずPRを通す
どんな小さな変更でも、
ブランチを切る
PRを作る
CIを通す
という流れを一度やってみる。
最初は自分一人のリポジトリでも構いません。
「PRを通してマージする」という型を体に入れるのが大事です。
ステップ2：PRの本文に「やったこと」と「テスト」を必ず書く
「何をしたか」と「どう確認したか」を、
毎回PRに書く習慣をつける。
これは、レビューする人のためでもあり、
未来の自分のためでもあります。
ステップ3：小さな変更ごとにPRを分けてみる
「ついでにこれも直そう」をぐっとこらえて、
1PR = 1目的 を意識してみる。
これを続けると、
自然と「変更を小さく切る」感覚が身についてきます。
まとめ（Pull Requestは「main に入れる前に、機械と人間でちゃんと確認するための窓口」）
初心者目線で整理すると、Pull Request はこういうものです。
自分のブランチで行った変更を、main に取り込んでいいかどうかを、CI（自動テスト）とレビュー（人間の目）を通して確認するための“申請書兼、会話の場”。
PRを小さく保ち、本文に「やったこと」と「テスト」を書き、CIを必須にすることで、「壊れたコードがmainに混ざる」リスクを下げつつ、設計や命名についてのフィードバックも得られる。
最初は一人開発でもいいから、「mainに直接pushしない」「必ずPRを作る」「PRにテスト結果を書く」という3つを回してみると、Pull Requestが単なるボタンではなく、品質とチーム開発の土台だという感覚が掴めてくる。