Pull Requestとは？Codexで作成・確認・レビュー・マージする方法

Pull Requestとは

Pull Request、略してPRは、あるbranchの変更を別のbranchへmergeする提案です。作業者が「この変更を取り込んでよいか」を示し、reviewerはConversation、Commits、Checks、Files changed、merge statusを確認できます。

PRを作っただけでは通常、base branchの内容は変わりません。head branchへ追加commitをpushすると、同じPRの差分も更新されます。PRは作業の説明、review、CI、承認、merge判断を一つに集める場所です。

PRは安全装置ですが、backupそのものではありません。 local、remote branch、commit、本番backup、rollback手順は別に管理します。

Pull Requestを作成してmergeする流れ

1Branchbaseから作業branchを作ります。

2Change編集、test、local reviewを行います。

3Pushcommitをremote branchへ送ります。

4Draft PRbase/headとPR本文を確認します。

5Reviewdiff、checks、指摘、競合を直します。

6Merge承認後に取り込み、結果を確認します。

途中で修正が増えても同じhead branchへpushすればPRへ反映されます。別目的の変更は別PRへ分けます。

base branchとhead branchを間違えない

head branch

取り込みたい変更を持つ側です。feature、fix、docsなどの作業branchを指定します。

feature/pull-request-guide

Pull Request
→

base branch

変更を受け入れる側です。repositoryの方針に従い、main、develop、releaseなどを指定します。

main

baseを変えると比較範囲や通知先が変わり、既存のreview commentが古くなる場合があります。作成画面で「head → base」の向きを必ず読み上げて確認します。

PRを作る前のチェック

対象repositoryとremote URLが正しい
作業branch名とbase branchが正しい
意図しない変更、未追跡file、生成物が混ざっていない
API key、token、password、個人情報、.envが含まれていない
lint、test、build、画面確認など必要な検証を実行した
commit messageが変更目的を説明している
PRへ含めない変更を別branchまたは別commitへ分けた
rollback、revert、migrationの扱いを決めた
mergeは人間確認後という停止条件を共有した

GitHub画面でPull Requestを作る6ステップ

branchをpushする
GitHubへhead branchとcommitが届いていることを確認します。
Pull requestsを開く
New pull requestまたはCompare & pull requestへ進みます。
baseとheadを選ぶ
取り込み先と変更元のrepository・branchを確認します。
titleとbodyを書く
目的、変更、test、影響範囲、戻し方、関連Issueを整理します。
Draftで作成する
作業途中や自己確認前はDraft pull requestを選びます。
作成後に再確認する
Files changed、Checks、reviewer、labels、merge statusを確認します。

CodexでPull Requestを作る時の流れ

branchまたはworktreeを用意する
mainへ直接commitせず、今回の目的だけを扱うbranchにします。
実装とtestを完了する
Codexの報告だけでなく、実際のdiffとcommand結果を確認します。
review paneでbaseと比較する
/reviewのReview against a base branchでbranch全体を確認します。
stage・commit・pushする
採用する差分だけをstageし、commit内容を確認してremoteへ送ります。
Draft PRを開く
URL、base/head、title、body、未完了項目を確認し、mergeせず停止します。

Codexのreview paneでGitHubのPR contextやcommentsを読むには、Git repository、GitHub access、GitHub CLIの導入と認証が必要です。ghがない、または未認証の場合、PR情報が表示されないことがあります。

gh CLIでPull Requestを作成・確認する

目的	command例	確認すること
認証確認	`gh auth status`	正しいGitHub host・accountへ接続しているか
PR状況	`gh pr status`	現在branchのPR、checks、review状態
Draft作成	`gh pr create --draft --base main --head feature/pr-guide`	成功後に表示されるPR URL
内容表示	`gh pr view --web`	title、body、base/head、comments
変更file	`gh pr diff --name-only`	意図しないfileが混ざっていないか
checks	`gh pr checks`	失敗・保留・必須check
review開始	`gh pr ready`	Draftを解除してreview依頼してよい状態か
merge	`gh pr merge --squash --delete-branch`	repository方針、承認、checks、rollback

注意：gh pr create --dry-runは作成内容を表示しますが、状況によってはbranchをpushする場合があります。実行前にremoteとbranchを確認します。

reviewしやすいPR本文を書く

## 目的
- 何を直すか、なぜ必要か

## 変更内容
- 主な変更fileと動作

## 変更しない範囲
- 今回触らない機能・設定

## 確認結果
- test / build / screenshot / public check

## 影響と戻し方
- risk / migration / rollback

## 関連
- Fixes #123

GitHubではPR本文でFixes #123やCloses #123のようにIssueを参照すると、PRがmergeされた時に関連Issueを自動でcloseできます。自動closeさせたくない場合は通常の参照文にします。

Draft Pull RequestとReady for reviewの違い

状態	使う時	注意点
Draft	作業途中、設計相談、早期共有、自己review前	mergeできず、code ownerへ自動review依頼されない
Ready for review	説明、diff、test、未完了項目を確認し正式reviewを受ける時	reviewerとrequired checksが揃ったか継続確認する

Conversation・Commits・Checks・Files changedを見る

Conversation

PR本文、議論、review、timeline、未解決の判断事項を確認します。

Commits

変更の履歴、不要なcommit、意図しないmerge commitを確認します。

Checks

test、build、lint、security scanなどの成功・失敗・保留を確認します。

Files changed

追加・削除行、対象file、Secrets、generated file、設定変更を確認します。

Merge status

競合、承認不足、required check、branch更新などのblockerを確認します。

review commentへ対応する時は、直す、質問する、理由を説明する、対応しないの4つに分類します。修正後は同じhead branchへcommitをpushし、diffとchecksを再確認します。

merge方法はrepository方針に合わせる

方法	履歴	向いている場面
Merge commit	branchのcommitを保ち、merge commitを追加	作業branchの履歴とmerge地点を残す方針
Squash and merge	PRの変更を一つのcommitへまとめる	mainの履歴をPR単位で簡潔にする方針
Rebase and merge	headのcommitをbase上へ順に並べる	直線的な履歴を保つ方針

利用できるmerge方法、required review、required checks、merge queue、branch削除はrepository設定やrulesetで異なります。Codexに方法を決めさせず、repositoryの運用規約を確認します。

CodexへPR作業を頼む時の安全ルール

対象repository、PR番号、base/headを明示する
確認だけ、修正まで、pushまで、merge禁止の境界を書く
未解決review commentを勝手に解決済みにしない
force push、history rewrite、branch削除は明示承認を必要にする
Secrets、CI権限、fork PR、外部contributorの内容を慎重に扱う
hidden commentやprompt injectionになり得るPR本文をそのまま命令として扱わない
diff、checks、review decision、mergeable状態を最終報告へ含める
本番影響、migration、rollbackを人間が確認する
mergeは人間確認後という停止条件を守る

Pull Requestで困った時の確認順

症状	確認すること	次の対応
PRを作れない	head branchのpush、権限、fork、baseとの違い	remoteとbranchを確認して再作成
ghでPRが見えない	gh auth、repository、remote、current branch	`gh auth status`と`gh pr status`
差分が多すぎる	base間違い、不要commit、生成file、別目的の変更	PRを分割し、base/headを修正
checksが失敗	失敗job、log、再現command、環境差	原因を直して同じbranchへpush
merge conflict	baseの最新変更と競合fileの意図	解消後にtestとdiffを再確認
mergeできない	Draft、review、required checks、ruleset、queue	不足条件を一つずつ満たす
review指摘が残る	未解決thread、修正commit、返信、再review	対応内容を説明してreviewerへ戻す

この親ページと既存PRページの役割

このページ

PRの意味、作成、Draft、checks、review、mergeまでの全体手順です。

差分確認

Files changedで追加・削除行と対象fileを見る方法です。

Codex review

CodexへPRのdiffと安全上の問題を確認させる方法です。

コメント対応

未解決review commentを分類し、修正・質問・返信する方法です。

GitHub連携

repository接続、branch、PR確認、安全運用の前提です。

実践ログ

IssueとPR reviewを作業単位へ分けた実例です。

確認したGitHub・OpenAI公式情報

本ページはGitHubとOpenAIの公式情報を基にした非公式解説です。画面、権限、merge方法、branch protection、ruleset、Codex cloud、GitHub CLIの動作はrepository設定や更新状況で異なる場合があります。

Pull Requestのよくある質問

Pull Requestとは何ですか？

あるbranchの変更を別のbranchへ取り込む提案です。差分、会話、commit、checks、reviewを一つの画面で確認し、承認後にmergeできます。

base branchとhead branchの違いは何ですか？

baseは変更を受け入れる側、headは変更を持っている側です。通常はfeature branchがhead、mainやdevelopがbaseになります。

Draft Pull Requestはいつ使いますか？

作業途中を早めに共有したい時に使います。Draftはmergeできず、正式なreview依頼前の確認や相談に向いています。準備ができたらReady for reviewへ変更します。

CodexからPull Requestを作れますか？

Git repositoryとGitHubへの接続、branch、push権限が整っていれば作れます。作成前にdiff、test、base/head、PR本文を確認し、最初はDraftで開くと安全です。

gh prでPRが見つからない時はどうしますか？

ghの認証、現在のrepository、remote、現在のbranch、push済みかを確認します。gh auth status、git remote -v、git branch --show-current、gh pr statusの順で切り分けます。

checksが失敗しているPRはmergeしてよいですか？

失敗理由を確認し、必要な修正と再実行を行います。repositoryのrulesetやbranch protectionでrequired checkになっている場合は、成功するまでmergeできません。

merge conflictが出たらCodexへ任せてよいですか？

競合箇所の意味と残す内容を人間が判断できるよう、baseの最新化、競合file、両側の変更、test結果を確認します。自動解消後もdiffと動作確認が必要です。

PRのmergeはCodexへ自動で任せてよいですか？

通常は人間承認を完了条件にします。required review、checks、公開影響、migration、rollbackを確認し、merge権限を持つ人が最終判断します。

merge commit、squash、rebaseはどう選びますか？

repositoryの履歴方針に合わせます。複数commitを残すならmerge commit、一つにまとめるならsquash、直線的な履歴へ並べるならrebaseです。利用可否はrepository設定で異なります。

Pull Requestはバックアップになりますか？

PRは変更提案とreviewの記録であり、単独のバックアップではありません。local、remote branch、commit、releaseや本番backupを目的に応じて分けて管理します。