GitHubなどのバージョン管理サービスでよく目にする「プルリクエスト（Pull Request）」。
はじめて見る人にとっては、「これって何？」「どうやって使うの？」「失敗したらどうしよう」と不安になるものです。
この記事では、初心者向けにプルリクエストの基本的な仕組み・出し方・レビュー対応・マナーまでわかりやすく解説します。
プルリクエストとは？
プルリクエスト（略して「PR」）とは、**自分が修正・追加したコードをプロジェクト本体に取り込んでもらうための「申請」**のことです。
GitHubなどでは、開発者が以下のような流れでコードを提出します：
- プロジェクトを自分の環境にコピー（フォーク＆クローン）
- 修正や新機能を別ブランチで開発
- プロジェクトに「この変更をマージしてほしい」とPRを送る
- プロジェクト管理者や他の開発者がレビュー
- 問題なければマージ（＝本体に取り込まれる）
つまり、PRはチーム開発における「相談」と「提案」の場です。
どうやって出すの？基本的なPRの手順
- リポジトリをフォークする（外部プロジェクトの場合）
- ローカルにクローンして、作業用ブランチを作成
git checkout -b fix-typo-readme - コードを修正・保存・コミット
git add . git commit -m "Fix typo in README" - GitHubにプッシュする
git push origin fix-typo-readme - GitHubで「Compare & Pull Request」ボタンを押す
- タイトル・説明を書いて提出！
PRを出すときのポイント
✅ 良いPRタイトルの例：
Fix typo in installation instructionsAdd validation to email input fieldRefactor login function for clarity
✅ PR本文に書くべき内容：
- 何を変更したか
- なぜその変更が必要だったか
- 動作確認した内容やスクリーンショット（UI変更時など）
- 関連Issueの番号（例：
Closes #42）
✅ 英語での一例（オープンソース向け）：
### Summary
Fixed a typo in the README file (`instalation` → `installation`).
### Motivation
Improve clarity for new users.
### Related issue
Closes #123
プルリクエスト時のマナー・注意点
| マナー・習慣 | 理由・効果 |
|---|---|
| 小さな変更単位でPRを出す | レビューしやすく、マージされやすくなる |
| コメントに丁寧な言葉を使う | オープンな場では協調性が評価される |
| READMEやドキュメントも更新 | コードだけでなく使い方や説明も重要 |
| 質問や相談も気軽にIssueへ | 無理にPRする前に「方向性確認」もあり |
PRを受けたときは？
もしチームでの開発や自分のOSSプロジェクトでPRを受けた場合は、以下を意識しましょう：
- レビューは「指摘」ではなく「協力」のスタンスで
- コメントには具体的な提案を添える
- よかったら「LGTM（Looks Good To Me）」と伝える
よくあるQ&A
Q. プルリクを出したら間違いに気づいた！どうすれば？
→ 自分のブランチで修正してコミット・プッシュすれば、PRに自動で反映されます。
Q. レビューコメントが厳しくて心が折れそう……
→ 技術的な議論と人格は別。ネガティブに受け止めず「次に活かす」ことが大事です。
Q. 1回目でマージされなかったら終わり？
→ そんなことはありません。修正を加えて再レビューしてもらえばOK！
まとめ：プルリクエストは「協力のはじまり」
プルリクエストは、コードのやり取りだけでなく、技術的なコミュニケーションと信頼の場です。
最初は勇気がいりますが、出してみることで得られる学びはとても大きなものになります。
「失敗しても恥じゃない」──それがOSSやチーム開発の良いところ。
あなたの1行の変更が、世界中の開発者やユーザーを助けるかもしれません。
