Gitでbranchを使えるようになると、次に覚えたいのがGitHubの**Pull Request（PR）**です。

Pull Requestは、単に「branchをmainへmergeするボタン」ではありません。変更内容、変更理由、commit、差分、レビュー結果などをひとつの単位にまとめ、この変更を取り込んでよいか確認するための変更提案です。

GitHub公式ドキュメントでも、Pull Requestはコード変更を提案し、merge前に議論・レビューするための主要な仕組みとして説明されています。

この記事では、小規模な個人開発を想定して、feature branchをpushしてからPull Requestを作成し、差分を確認してmainへmergeするまでを整理します。

Pull Requestとは

ローカルGitだけでもbranchをmainへmergeできます。しかしGitHub上でPull Requestを作ると、変更をmergeする前に「何を変えたか」「なぜ変えたか」「どのcommitが含まれるか」「実際の差分は何か」をまとめて確認できます。

基本形は次の流れです。

main
  ↓ branchを作る
feature/example
  ↓ 編集・commit
feature/example
  ↓ GitHubへpush
origin/feature/example
  ↓ Pull Request
main ← 変更提案
  ↓ 確認・merge
main

重要なのは、Pull Requestではbase branchと**compare branch（head/source branch）**を区別することです。

• base：変更を取り込みたい側。通常はmain
• compare：変更を含んでいる側。例：feature/example

つまり「feature/exampleの変更をmainへ取り込みたい」という関係をGitHub上に作るのがPull Requestです。

1. feature branchで変更をcommitする

まずmainから作業branchを作ります。

git switch main
git pull
git switch -c feature/example

ファイルを編集したら状態と差分を確認します。

git status
git diff

問題なければstageしてcommitします。

git add .
git commit -m "Add example change"

ここまでは変更がローカルrepositoryにある状態です。まだGitHubに新しいbranchが存在しない場合があります。

2. branchをGitHubへpushする

Pull Requestを作るには、変更を含むbranchをGitHub側から参照できる状態にします。

git push -u origin feature/example

-u（--set-upstream）を付けると、ローカルbranchとremote branchの追跡関係が設定されます。以後は状況に応じてgit pushだけでpushしやすくなります。

GitHub公式Quickstartでも、branchでcommitした後にbranchをpushし、そのbranchを使ってPull Requestを開く流れが示されています。

3. Pull Requestを作成する

GitHubでrepositoryを開き、pushしたbranchからPull Requestを作成します。

GitHubの画面表示は更新されることがあるため、ボタンの位置や文言を暗記するより、次の関係を確認することが重要です。

base: main
compare: feature/example

そのうえでタイトルと説明を書きます。

タイトルは変更内容を短く表します。

Add example calculation

説明には最低限、次を残すと後から理解しやすくなります。

## 変更内容
- example機能を追加

## 目的
- 操作確認のため

## 確認
- [x] ローカルで動作確認

個人開発でも「なぜ変更したか」をPull Requestに残しておくと、数週間後や数か月後に履歴を追うときの情報量が大きく変わります。

4. Conversationで変更の目的を見る

Pull RequestのConversationでは、PRの説明、コメント、レビュー、時系列の活動などを確認できます。

ここで見るべき中心は「なぜこの変更が必要なのか」です。

コード差分だけでは変更理由までは分からないことがあります。PR本文に目的と確認内容を残しておけば、変更の背景を履歴として保存できます。

個人開発では自分自身が未来のレビュアーになるため、短い説明でも残す価値があります。

5. Commitsで変更履歴を見る

Commitsでは、そのPull Requestに含まれるcommitを確認します。

確認したいのは次のような点です。

• 意図したcommitだけが含まれているか
• 関係のない変更が混ざっていないか
• commit messageから変更内容を追えるか

PRを作った後も同じhead branchへcommitを追加してpushすると、その変更は開いているPull Requestへ追加されます。

したがって、レビューで修正点が見つかった場合も、同じbranchを修正してcommit・pushすればPRを更新できます。

6. Files changedで実際の差分を見る

Files changedはPull Requestで特に重要な確認場所です。

ここではbase branchに対して、どのファイルのどの行が追加・削除・変更されるのかを確認できます。

チェックする観点は次のとおりです。

• 意図していないファイルが含まれていないか
• 一時ファイルや生成物を誤ってcommitしていないか
• 秘密情報が含まれていないか
• デバッグ用コードを残していないか
• 変更範囲が目的に対して大きすぎないか

ローカルで動いたことと、mergeしてよい変更であることは別です。Files changedを確認する習慣を付けると、誤った変更をmainへ入れる可能性を下げられます。

なお、現在のGitHub Pull RequestにはChecksなど追加の確認領域もあります。CIを導入したrepositoryでは、自動テストやbuild結果もmerge判断に利用できます。

7. Pull Requestをmergeする

内容を確認し、問題がなければPull Requestをmergeします。

GitHubではrepository設定や権限に応じて複数のmerge方法を利用できる場合があります。代表例は通常のmerge、squash merge、rebase mergeです。

最初の学習では、まずrepositoryで利用可能なmerge方法を確認し、標準設定の方法で一連の流れを経験すれば十分です。

重要なのは、mergeボタンを押す前に次を確認することです。

base branchは正しいか
変更差分は意図どおりか
不要なファイルはないか
必要なチェックは通っているか

merge後はPull Requestが「変更提案」から「取り込まれた変更の記録」になります。

8. merge後にbranchを削除する

mergeが完了した作業branchは、今後使わないなら削除できます。

GitHub上ではmerge後にbranch削除の操作が提示される場合があります。UIは変化する可能性があるため、表示位置ではなく「merge済みの作業branchを整理する操作」と理解しておきます。

ローカルbranchも不要なら、mainへ戻ってから削除できます。

git switch main
git pull
git branch -d feature/example

git pullでremote側のmainの更新をローカルへ反映してから状態を確認すると、GitHubとローカルの関係を理解しやすくなります。

個人開発でもPull Requestを使う理由

一人で開発している場合、「自分しかいないのだから直接mainへpushすればよい」と考えることもできます。小さな試作ではそれで十分な場合もあります。

それでも、継続して育てるrepositoryではPull Requestを使う価値があります。

変更単位が明確になる

branchとPull Requestを1つの目的に対応させると、「この変更では何をしたのか」が分離されます。

merge前に差分を読み直せる

自分が書いたコードでも、GitHubのdiffとして見ると不要な変更に気付くことがあります。

変更理由を履歴として残せる

commitは「何を変更したか」、Pull Request本文は「なぜ変更したか」を残す場所として使い分けられます。

将来の自動化につながる

Pull Requestを変更の単位にすると、CIによるtest、lint、build、レビューなどをmerge前のゲートとして追加できます。

個人開発でも、後から自動化を追加しやすい構造になります。

Pull Requestで覚えるべき最小フロー

最初は次の流れを繰り返せれば十分です。

git switch main
git pull
git switch -c feature/example

# ファイルを編集

git status
git diff
git add .
git commit -m "Add example change"
git push -u origin feature/example

その後GitHubで、

base: main
compare: feature/example
↓
Pull Request作成
↓
Conversation確認
↓
Commits確認
↓
Files changed確認
↓
merge
↓
不要なbranchを削除

という流れを実行します。

Pull Requestは「mergeするための画面」ではなく、変更をひとまとまりの提案として確認し、mainへ入れる前に品質を確認する境界と考えると理解しやすくなります。

まとめ

Pull Requestを使う基本フローは、branchで変更し、commitしてGitHubへpushし、そのbranchからmainへの変更提案を作ることです。

PRではConversationで目的や議論、Commitsで変更履歴、Files changedで実際の差分を確認します。必要な確認が終わってからmergeし、不要になった作業branchを整理します。

個人開発でもPull Requestを使うことで、変更理由と差分を一つの単位として保存できます。さらに将来、testやlintなどの自動チェックを追加するときにも、Pull Requestを品質ゲートとして発展させられます。

参考資料

• GitHub Docs: Pull requests
• GitHub Docs: Creating a pull request
• GitHub Docs: Quickstart for pull requests

※GitHubのWeb UI、タブ構成、ボタン名称、利用可能なmerge方法はGitHubの更新やrepository設定によって変わる可能性があります。本記事ではUIの位置よりも、baseとcompareの関係、差分確認、merge判断という不変性の高い概念を中心にしています。