Git/GitHub

Pull Request の最低セット

10

Pull Request(PR)は、ブランチの変更をレビューしてから合流するための仕組みです。ブランチを切って push → GitHub で PR を開く → base / compare を見てマージ、が最短ルートです。個人学習なら self-merge で構いません。

参考: About pull requests · Creating a PR · Merging a PR · gh pr create


目次

  1. Pull Request とは何か
  2. 流れ全体:branch → push → PR
  3. 1. 作業ブランチを切る
  4. 2. 変更してブランチを push する
  5. 3. GitHub 上で PR を開く
  6. base と compare の意味
  7. 説明文(description)の書き方 — 短く要点だけ
  8. レビュー後にマージする(UI から)
  9. gh コマンドで PR を作る(任意)
  10. うまくいかないとき

Pull Request とは何か

Pull Request は、「あるブランチの変更を、別のブランチに取り込みたい」という提案を GitHub 上で可視化する仕組みです。git merge そのものはローカルでもできますが、PR を使うと次のようなことが GitHub の画面上でできるようになります。

  • 変更差分(diff)をファイル単位・行単位で確認する
  • コメントでレビューする、変更を依頼する
  • CI(自動テストなど)の結果を確認する
  • 承認(Approve)を経てから、ボタン操作でマージする

個人開発であっても、「直接 main に commit せず、必ず PR を経由する」 というルールを自分に課すことで、チーム開発の感覚を先取りして練習できます。

feature ブランチで作業 → push → GitHub で PR 作成 → レビュー → マージ → main に反映

流れ全体:branch → push → PR

最低限の PR を作るまでの流れは、次の 3 ステップに要約できます。

1. git switch -c <ブランチ名>     … ローカルで作業ブランチを作る2. git push -u origin <ブランチ名> … ブランチをリモートに送る3. GitHub 上で "Compare & pull request" … PR を開く

以降、それぞれのステップを具体的に見ていきます。


1. 作業ブランチを切る

main から新しいブランチを作り、そこで作業します。main 上で直接編集しないのが PR フローの前提です。

git switch maingit pullgit switch -c add-readme-section

ブランチ名は、何をする変更か分かる短い英語表現にしておくと、後から PR 一覧を見返したときに把握しやすくなります(例: add-readme-sectionfix-typo-in-config)。

echo "## 使い方" >> README.mdecho "詳しい使い方はこちらに追記します。" >> README.mdgit add README.mdgit commit -m "README に使い方セクションを追加"

2. 変更してブランチを push する

作業ブランチを、まだリモートに存在しない新しいブランチとして push します。

git push -u origin add-readme-section
Total 3 (delta 1), reused 0 (delta 0)remote:remote: Create a pull request for 'add-readme-section' on GitHub by visiting:remote:      https://github.com/<user>/<repo>/pull/new/add-readme-sectionremote:To https://github.com/<user>/<repo>.git * [new branch]      add-readme-section -> add-readme-section

GitHub は push を受け取ると、その場で PR 作成用の URL をターミナルに表示してくれます。この URL をブラウザで開くのが最短ルートです。


3. GitHub 上で PR を開く

  1. リポジトリのページを開くと、直前に push したブランチに対して 「Compare & pull request」 というバナーが表示される
  2. バナーのボタンを押す(表示されない場合は、リポジトリの Pull requests タブ → New pull request から手動で選ぶ)
  3. base ブランチと compare ブランチが正しいか確認する(次節)
  4. タイトルと説明を書く
  5. Create pull request を押す

これで PR が 1 件作成されます。作成した時点ではまだ main には反映されておらず、レビュー・マージを経てから 反映される、という点が git merge を直接叩く場合との大きな違いです。


base と compare の意味

PR 作成画面には basecompare という 2 つのブランチ選択があります。

項目 意味
base 取り込み先のブランチ(通常は main
compare 取り込みたい変更が入っているブランチ(今回作った作業ブランチ)
base: main  ←────── compare: add-readme-section      (ここに取り込む)      (ここの変更を提案する)

矢印の向きは「compare の内容を base に合流する」という意味です。base を間違えて別のブランチに向けてしまうと、意図しないブランチに変更が入ってしまうため、PR を開く前に base/compare の両方を確認する習慣をつけます。

fork を使った OSS 貢献などでは、base が他人のリポジトリ、compare が自分の fork のブランチになるケースもありますが、個人学習の範囲では同一リポジトリ内の main ↔ 作業ブランチで十分です。


説明文(description)の書き方 — 短く要点だけ

個人学習の PR では、長い説明文を書く必要はありません。次の 3 点が分かれば十分です。

## 変更内容README に「使い方」セクションを追加した。## 理由新しく触る人が最初に見る導線が無かったため。## 確認方法README.md をブラウザ(GitHub 上)で表示し、見出しが表示されることを確認。
項目 書く内容 書かなくていいこと
変更内容 何を変えたか(1〜2行) 差分の全文(diff タブで見れる)
理由 なぜ必要か(1行でも良い) 長い背景説明
確認方法 どう動作確認したか 網羅的なテストケース一覧(学習段階では不要)

タイトルは commit メッセージと同様、「何をしたか」が一目で分かる短い文にします(例: 「README に使い方セクションを追加」)。


レビュー後にマージする(UI から)

チームで作業している場合は、レビュアーが Approve(承認)した後にマージします。個人開発で自分しかレビュアーがいない場合は、自分で内容を見直してから自分でマージ(self-merge)して構いません。学習目的であれば、PR を経由する流れそのものを体験することが重要です。

  1. PR ページ下部の Merge pull request ボタンを押す
  2. マージ方法を選ぶ(種類は次の表)
  3. Confirm merge を押す
  4. 不要になった作業ブランチは Delete branch で削除する(任意)
マージ方法 履歴の残り方
Create a merge commit 通常の merge commit(分岐がそのまま残る)
Squash and merge 作業ブランチの複数コミットを 1 つにまとめて合流
Rebase and merge 作業ブランチのコミットを base の先端に付け替えて合流

どれを選ぶかはチームの方針次第ですが、迷う場合は既定の Create a merge commit で構いません。マージ後は、ローカルの main を最新化しておきます。

git switch maingit pull

gh コマンドで PR を作る(任意)

GitHub CLI(gh)を使うと、ブラウザを開かずにターミナルから PR を作成できます。インストール済みであれば、次のように使います。

gh pr create --base main --head add-readme-section --title "README に使い方セクションを追加" --body "README に使い方セクションを追加した。"

対話的に入力したい場合は、オプションを省略して実行すると質問形式で埋めていけます。

gh pr create

作成した PR をブラウザで確認したいときは次を使います。

gh pr view --web

gh は必須ではなく、あくまで ブラウザ操作を短縮するための任意のツールです。まずはブラウザの UI で一通りの流れを経験してから、慣れてきたタイミングで gh に置き換えると理解しやすくなります。


うまくいかないとき

「Compare & pull request」のバナーが出ない

push が正しく完了しているか、git statusgit branch -vv で追跡ブランチを確認します。バナーが出なくても、リポジトリの Pull requests タブ → New pull request から base/compare を手動で選べば同じ PR を作成できます。

base ブランチを間違えて PR を作ってしまった

マージする前であれば、PR ページ上部の base ブランチ表示の横にある編集操作から変更できます(GitHub の画面バージョンによって操作場所は変わります)。心配な場合は一度 PR を閉じて(Close)、正しい base で作り直しても問題ありません。

PR に「This branch has conflicts that must be resolved」と出る

base ブランチ側が PR 作成後に進み、compare ブランチとの間でコンフリクトが起きた状態です。ローカルで main を取り込んで解消します。

git switch add-readme-sectiongit fetch origingit merge origin/main# コンフリクトを解消して add / commitgit push

push すれば PR 側にも自動で反映され、コンフリクト表示が消えます。

Merge ボタンが押せない(グレーアウトしている)

必須のステータスチェック(CI)が失敗している、必須レビュー数を満たしていない、またはブランチ保護ルールに引っかかっていることが多いです。個人リポジトリで意図せずこの状態になった場合は、リポジトリの Settings > Branches の保護ルールを見直します。

self-merge していいのか迷う

個人の学習用リポジトリで自分以外にレビュアーがいない場合、self-merge は問題ありません。重要なのは「直接 main に commit せず、必ずブランチ・push・PR という手順を通す」こと自体の練習であり、承認者が誰であるかは学習段階では優先度が低い論点です。

シェア