プルリクエストとは？GitHub での作り方・レビュー・マージの基本（3 つの方式の違いまで）

プルリクエスト（pull request）は、あるブランチのコードの変更を、別のブランチにマージする（取り込む）ことを提案する、GitHub の機能です。ブランチは、変更を分けて進めるための枝のようなものです。取り込む前に、変更を見せて、話し合って、レビューしてもらう場になります。この記事は、GitHub を使い始めた初心者向けに、プルリクエストの考え方、作り方（GitHub の画面と gh コマンド）、レビューの見方、マージの 3 つの方式の違い、マージしないときや取り消すときの方法を、2026年10月時点の GitHub Docs（英語版）をもとにまとめたものです。

GitHub に push するための接続（SSH や HTTPS）の設定は、GitHub の SSH 設定入門で説明しています。

この記事でわかること

プルリクエストとは何か、push との違い、公式が挙げる「使う理由」と流れ
作る前の準備（ブランチ・コミット・push、書き込み権限が無いときのフォーク）と、画面と gh での作り方、下書き（draft）の使い方
レビューのやり方と、Comment・Approve・Request changes の違い（Request changes がマージを止めるのはどんなときか）
マージの 3 つの方式（Merge commit・Squash and merge・Rebase and merge）の違いと、手元の Git での履歴の形
マージしないとき・取り消すとき・GitLab の「マージリクエスト」との違い

プルリクエストとは？push との違いは？
プルリクエストを作る前に何をする？（ブランチ・コミット・push）
プルリクエストの作り方は？（画面・gh・下書き）
レビューはどう進める？（Comment・Approve・Request changes）
マージの 3 つの方式（Merge commit・Squash and merge・Rebase and merge）の違いは？
マージしないとき・取り消すときはどうする？
GitLab の「マージリクエスト」とは何が違う？
よくある質問
まとめ
参考資料

プルリクエストとは？push との違いは？

GitHub Docs は、プルリクエストを「あるブランチのコードの変更を、別のブランチにマージすることを提案するもの」と説明しています。共同作業のための機能で、変更がプロジェクトに入る前に、話し合ってレビューする場になります。

GitHub の用語集では、プルリクエストは「利用者が出したリポジトリへの変更の提案で、リポジトリの共同作業者（collaborator）が受け入れるか断るもの」です。Issue（課題を書いておく場所）と同じように、プルリクエストごとに話し合いの場があります。マージ（merge）は、あるブランチの変更を別のブランチに当てはめることで、プルリクエストは「マージしてほしいという依頼」と考えられる、と用語集は書いています。

push との違い

push（プッシュ）は、コミット（変更を記録した単位）を、GitHub.com にあるリモートリポジトリに送ることです。送るだけで、「取り込んでください」という依頼は含みません。プルリクエストは、push したブランチの変更を、別のブランチに取り込んでもらうための提案です。そのため、先にブランチを push してから、プルリクエストを出します。

使う理由

公式は、プルリクエストを使う理由を 3 つ挙げています（プルリクエストについて）。

main ブランチに入る前に、バグや問題を早く見つける
特定の行に結びついたフィードバックで、一緒に話し合って直す
何がなぜ変わったかの履歴を、あとで見直せる形で残す

プルリクエストでできることとして、公式はこのほかに、テスト・ビルド・コードスキャンなどの自動チェックを変更に対して走らせること、レビューと必須のチェックが済んだらマージすることも挙げています。

流れ

公式が示すプルリクエストの流れは、次の 5 段階です。

ブランチを作るか、リポジトリをフォークして、作業用に切り離した場所を用意する
変更をコミットする
プルリクエストを開いて、変更を base branch にマージすることを提案する
共同作業者とレビュー・話し合いをして、必要なら更新する
準備ができたらマージする

base branch と head branch

プルリクエストには、2 つのブランチが出てきます。

用語	意味
base branch	マージしたときに、変更が取り込まれる側のブランチ
head branch（compare branch とも呼ぶ）	変更を持っている側のブランチ

プルリクエストは、head branch の変更を base branch と比べます。プルリクエストは、2 つの異なるブランチの間でしか開けません。作るときに、どのブランチへマージするか（base）を選べます。GitHub で新しく作ったリポジトリの既定のブランチ名は main で、別に指定しなければ、既定のブランチが新しいプルリクエストの base branch になります（Branches）。

プルリクエストの画面

プルリクエストの画面の主な部分は、次のとおりです（プルリクエストについて）。タブの名前は、公式の英語版の表記です。

部分	見えるもの
Conversation	説明・コメント・レビュー・経過
Commits	ブランチがどう変わってきたか
Checks	自動テストやビルドの結果
Files changed	レビューする人がコメントする差分（変更の差）
merge box	マージできるか、あと何が要るか

公式の参照ページには、5 つ目のタブとして Findings（コードスキャンのアラートなど、自動のレビュー結果）も挙がっています。

プルリクエストを作る前に何をする？（ブランチ・コミット・push）

プルリクエストは、変更を入れたブランチが GitHub にある状態で出します（手元で作ったブランチなら、先に push します）。機能を作るためのブランチは、ふつう feature branch や topic branch と呼ばれます。ブランチは既存のブランチから作り、ふつうはリポジトリの既定のブランチから作ります。

書き込み権限があるときとないとき

使い方は、公式の説明では開発のモデルで 2 通りに分かれます（Pull requests の参照ページ）。

モデル	中身	多いところ
共有リポジトリモデル	共同作業者が 1 つのリポジトリに push でき、変更のたびに topic branch を作る	小さなチームや組織の非公開のプロジェクト
フォーク＆プルモデル	元の（upstream）リポジトリをフォークして、そこから出す	新しい貢献者の手間が少ないので、オープンソース

リポジトリに書き込む権限が無いときは、先にリポジトリをフォークします。フォークは、ほかの人のリポジトリを自分のアカウントに写した個人用のコピーです。元のリポジトリに影響せずに自由に変えられて、元のリポジトリへプルリクエストを出せます。

コマンドで始める流れ

公式のクイックスタートに、gh（GitHub CLI）を使った始め方があります。書き込み権限があれば gh repo clone、無ければフォークとクローンを一度に行う gh repo fork を使います。そのあと、git checkout -b で新しいブランチを作って移ります。

# 書き込み権限があるとき
gh repo clone OWNER/REPO

# 書き込み権限が無いとき（フォークとクローンを一度に行う）
gh repo fork OWNER/REPO --clone

cd REPO

# 新しいブランチを作って移る
git checkout -b YOUR-BRANCH-NAME

OWNER/REPO は、リポジトリの持ち主の名前とリポジトリの名前に、YOUR-BRANCH-NAME は自分で付けるブランチの名前に置き換えます。

ブラウザでブランチを作ることもできます。ファイル一覧の上にあるブランチのメニュー（たぶん main と出ています）をクリックし、新しいブランチの名前を打って、Create branch *new-branch-name* from main をクリックします。

小さくコミットして push する

変更は、小さく意味のあるコミットで保存します。そのあと、ブランチを push します。

git add .
git commit -m "Describe your change"
git push --set-upstream origin YOUR-BRANCH-NAME

--set-upstream を付けると、手元のブランチが、origin（リモートの既定の名前）の同じ名前のブランチを追うように設定されます。GitHub に push するための接続の設定は、GitHub の SSH 設定入門で説明しています。

最初のプルリクエストは、変更を絞って簡単にするのが公式のすすめです。小さいプルリクエストのほうが、早くレビューされ、マージしやすいからです。レビューしてもらいやすくするための考え方として、公式は次の 3 点を挙げています（Helping others review your changes）。

小さく、1 つの目的に絞る。大きくなったら分けることを考える
題と説明に、なぜ変えたか・何を変えたか・どこを特に見てほしいかを書く
人に頼む前に、自分で差分を見直す（うっかりの変更が無いか、ビルドやテストを走らせたか）

プルリクエストの作り方は？（画面・gh・下書き）

GitHub の画面で作る

GitHub Docs の「プルリクエストを作成する」の手順は、次のとおりです。ボタンの名前は、この手順のページ（英語版）の表記にそろえています。GitHub の画面そのものは、この記事では確認していません。日本語版の文書のボタン名は文書の訳で、画面の表記と同じとは限らないため、英語で書いています。

リポジトリのページを開きます。
"Branch" メニューで、自分のコミットがあるブランチを選びます。
ファイル一覧の上の黄色い帯にある Compare & pull request をクリックします。
*base* ブランチのメニューで、変更を取り込みたいブランチを選びます。*compare* ブランチのメニューで、変更を入れたブランチを選びます。
プルリクエストの題と説明を書きます。
Create Pull Request をクリックします。

クイックスタートには、別の入り口も書かれています。リポジトリのページの Pull requests タブから New pull request を選び、base と compare を選んで、題と、何をなぜ変えたかの説明を書き、Create pull request を押す流れです。ボタンの大文字・小文字は、ページによって違います（作り方のページは Create Pull Request、クイックスタートは Create pull request）。どちらが今の画面の表記かは、確認していません。

下書き（draft）で作る・戻す

下書き（draft）のプルリクエストは、マージできず、コードオーナー（CODEOWNERS に書かれた人）にもレビューの依頼が自動では行きません。正式にレビューを頼まずに、作業中のものを見せたいときに使います。

下書きで作る: Create Pull Request の横のメニューで Create Draft Pull Request を選び、Draft Pull Request をクリックします。組織（Organization）のメンバーは、下書きを使うために、組織の持ち主へ申し出る必要があることがあります。どのプランで使えるかは、GitHub のプランのページには書かれていません。
レビューの準備ができたら: リポジトリ名の下の Pull requests から対象のプルリクエストを開き、merge box の Ready for review をクリックします。するとコードオーナーにレビューの依頼が行きます。
下書きに戻す: 出したあとでも、いつでも下書きに戻せます。右のサイドバーの "Reviewers" の下にある Convert to draft をクリックし、もう一度 Convert to draft をクリックします。戻すと、また Ready for review にするまで、誰もマージできません。

gh コマンドで作る

gh pr create で、プルリクエストを作れます。題と本文を聞かれます。作れると、プルリクエストの URL が表示されます。

gh pr create

聞かれずに済ませたいときは、--title と --body を付けます。--fill を付けると、題と本文をコミットから自動で埋めます。公式の例は次のとおりです。

gh pr create --title "The bug is fixed" --body "Everything works again"

よく使うフラグを表にまとめます（gh pr create --help の説明にもとづきます）。

フラグ	意味
`-B`, `--base`	取り込み先のブランチ。指定しなければ、ブランチの設定 `gh-merge-base`、それも無ければリポジトリの既定のブランチ
`-H`, `--head`	変更のあるブランチ。既定は今のブランチ
`-d`, `--draft`	下書きにする
`-r`, `--reviewer`	レビューを頼む人かチーム
`-a`, `--assignee`	担当を割り当てる。`@me` で自分
`-l`, `--label`	ラベルを付ける
`-w`, `--web`	ブラウザで作る画面を開く
`-T`, `--template`	テンプレートのファイル

別名は gh pr new です。今のブランチがまだ push されていなければ、どこへ push するかを聞かれ、元のリポジトリをフォークする選択肢も出ます。--head を付けると、フォークも push もしません。

対話で進めると、最後に "What's next?" と聞かれ、"Submit"・"Submit as draft"・"Continue in browser"・"Add metadata"・"Cancel" から選びます（gh のソースコードにある文面です。場合によって出ない選択肢があります。たとえば下書きを指定したときは "Submit" が出ません。画面での見え方は確認していません）。

注意: --dry-run は、作らずに中身を表示するフラグですが、説明に "May still push git changes." とあるとおり、git の push はしてしまうことがあります。試しのつもりで付けても、push されることがあります。

--attach を使うと、画像や動画のファイルを添付できます。このフラグは gh 2.99.0（2026年9月1日）から入りました。2026年10月10日時点の最新版は 2.102.0 です。古い gh では使えないので、gh --version で確かめてください。

出したあとに直す

出したあとに直すには、同じブランチ（head branch）にコミットを足して push します。同じブランチへのコミットは、自動でそのプルリクエストに加わります。GitHub の画面でも、Files changed タブで、ファイルの上のメニューから Edit file を選んで直せます。直すときは、head branch に直接コミットする選択をします。

Issue と結びつける・テンプレートを使う

プルリクエストの説明（またはコミットメッセージ）に Closes #10 のようにキーワードと Issue の番号を書くと（同じリポジトリの Issue なら KEYWORD #ISSUE-NUMBER の形）、マージしたときにその Issue が自動で閉じます。使えるキーワードは、close・closes・closed・fix・fixes・fixed・resolve・resolves・resolved です。

注意: このキーワードは、リポジトリの既定のブランチに向けたプルリクエストでだけ効きます。ほかのブランチに向けたプルリクエストでは、キーワードは無視され、リンクも作られず、マージしても Issue に影響しません（公式の説明）。

リポジトリに pull_request_template.md（リポジトリの直下）、docs/pull_request_template.md、.github/pull_request_template.md のどれかを置くと、プルリクエストの本文に、その中身が自動で入ります。中身の例として、公式は、関係する Issue への参照、変更の説明、レビューの担当への @メンションを挙げています。

レビューはどう進める？（Comment・Approve・Request changes）

プルリクエストのレビューは、マージの前に、変更へコメントし、改善を提案し、承認するか変更を求めるものです。リポジトリの読み取り権限があれば、誰でもレビューとコメントができます（Pull request reviews）。

レビューを頼む

レビューを頼むには、プルリクエストの右側の Reviewers を使います。候補の人の名前の横の Request をクリックするか、Reviewers をクリックして名前を入れます。頼むにはリポジトリへの書き込み権限が必要で、頼める相手は、リポジトリの読み取り権限がある人かチームです。頼まれた側には通知が届きます。Reviewers の欄が使えないときは、リポジトリの README にあるレビューの案内に従うか、レビューできる人にプルリクエストのリンクを送ります（Quickstart for pull requests・Requesting a pull request review）。

レビューをする側の手順

レビューする人の手順は、次のとおりです（Reviewing proposed changes in a pull request）。

プルリクエストの Files changed タブを開きます。
コメントしたい行にマウスを乗せて、青いコメントのアイコンをクリックします。複数行にコメントするときは、行番号をドラッグするか、Shift を押しながらクリックします。
コメントを書き、Start a review をクリックします。すでにレビューを始めているときは、Add review comment をクリックします。
変更の上にある Review changes をクリックします。
全体のまとめのコメントを書きます。
Comment・Approve・Request changes のどれかを選びます。
Submit review をクリックします。

レビューを出す前の行コメントは *pending*（保留中）で、自分にしか見えません。出す前なら、いつでも直せます。

コメントは 2 か所で書けます。Conversation タブには全体へのコメントや質問、お礼を書き、Files changed タブには特定のファイルや行へのコメントを書きます。メールで返信したコメントは Conversation タブに入り、レビューの一部にはなりません。

行の書き換えを「提案」することもできます。コメント欄の提案（Suggestion）のアイコンを押して、提案のブロックを編集すると、作者が Commit suggestion でそのまま取り込めます。いくつかまとめて取り込むなら、Add suggestion to batch のあとに Commit suggestions を使います。取り込むと、プルリクエストの compare ブランチに 1 つのコミットができ、提案した人は共同作者（co-author）になります。取り込むには、リポジトリへの書き込み権限が必要です。

3 つの選択肢の違い

レビューを出すときは、次の 3 つから 1 つを選びます。

選択肢	意味
Comment	承認も変更の依頼もはっきりさせずに、全体の意見を残す
Approve	マージしてよい状態だと示す
Request changes	マージの前に作者が対応すべき指摘だと示す

Request changes は、それだけではマージを止めません。 公式は、"purely informational"（情報として伝えるだけ）で、ルールセットか従来の保護ブランチのルールで "require a pull request" が設定されているときだけ、マージを止めると書いています。設定があるときに、admin・owner・write の権限を持つ人が Request changes を出すと、同じ人が承認のレビューを出し直すまで、そのプルリクエストはマージできません。このルールが設定されていなければ、Request changes を出したことだけでは、マージは止まりません。

もう 1 つ、作者は自分のプルリクエストを承認（Approve）できません。リポジトリの持ち主と管理者は、承認のレビューが無くてもマージできます。

LGTM と Approve は別もの

レビューのコメントで「LGTM」という言葉を見かけることがあります。意味や使われ方は、LGTM generatorで開発チームの雰囲気変えませんか？で説明しています。ただし、GitHub のレビューで「承認」として記録されるのは、Approve を選んで出したレビューです。Comment を選んで出したレビューは、本文に何と書いても、承認も変更の依頼もはっきりさせないレビューとして扱われます。

指摘に対応する

指摘をもらったら、提案は Commit suggestion で取り込みます。大きな直しは、コードを直して同じブランチに push します。プルリクエストは自動で更新され、チェックも走り直します。対応した会話は Resolved にします。もう一度見てほしいときは、Conversation タブのサイドバーにある再レビューのアイコンから、レビューをもう一度頼めます。直している間は、下書きに戻しておくこともできます。

gh でレビューする

gh pr review でも、レビューを出せます。番号を付けなければ、今のブランチのプルリクエストが対象です。

# 承認する
gh pr review --approve

# コメントする
gh pr review --comment -b "コメントの内容"

# 変更を依頼する（番号を付けて指定する例）
gh pr review 123 -r -b "直してほしい理由"

-b はレビューの本文の指定です。

マージの 3 つの方式（Merge commit・Squash and merge・Rebase and merge）の違いは？

レビューと必須のチェックが済んだら、マージします。GitHub のプルリクエストのマージには、3 つの方式があります。公式の比較表（Pull request merges）を、訳してまとめます。

方式	何をするか	向くとき
Merge commit	プルリクエストのブランチのコミットを全部残し、はっきりしたマージの点を足す	履歴を全部残したい。個々のコミットに意味がある
Squash and merge	プルリクエストの全コミットを、base branch 上の 1 つのコミットにまとめる	1 つのまとまった変更で、小さな直しのコミットが多い
Rebase and merge	マージコミットを作らずに、各コミットを base branch に足して、一直線の履歴にする	一直線の履歴にしたく、コミットがすでに整理されている

マージコミットは、2 つのブランチの履歴が合流した点を表すコミットです。

手元の Git で、履歴の形を並べると

3 つの方式で、履歴がどんな形になるかを、手元の Git で並べます。出発点は、main に A と C、feature に B と D があり、B と D は A から枝分かれした形です。次の 3 つは、手元の Git のコマンド（git merge --no-ff、git merge --squash、git rebase と git merge --ff-only）の例で、GitHub のボタンの中の動きを見たものではありません。コマンドの途中の出力は略しています（git 2.39.3 で確認した結果です）。GitHub の中の動きは、このあとの各方式の説明のとおりです。

Merge commit に近い形（git merge --no-ff）です。枝分かれとマージコミットが残ります。

$ git merge --no-ff -m "Merge branch 'feature'" feature
$ git log --graph --format='%h %s' main
*   5a0a986 Merge branch 'feature'
|\
| * 4f2a940 D: feature 2
| * c420abd B: feature 1
* | 7896b39 C: main
|/
* e1a59e6 A: first

Squash and merge に近い形（git merge --squash のあとに git commit）です。main には、まとめた 1 つのコミットだけが入り、B と D は入りません。

$ git merge --squash feature
$ git commit -m "Feature (squashed)"
$ git log --graph --format='%h %s' main
* 8fa0352 Feature (squashed)
* 7896b39 C: main
* e1a59e6 A: first

Rebase and merge に近い形（git rebase main のあとに git merge --ff-only）です。A・C・B・D の一直線になります。B と D の ID（SHA）は、元と違うものになります（c420abd が f6fe63b に、4f2a940 が 50f8333 に変わりました）。

$ git switch feature && git rebase main
$ git switch main && git merge --ff-only feature
$ git log --graph --format='%h %s' main
* 50f8333 D: feature 2
* f6fe63b B: feature 1
* 7896b39 C: main
* e1a59e6 A: first

手元の Git の merge と rebase の違いは、【完全入門】Git MergeとRebaseの違いと使い分けの話で詳しく説明しています。

方式ごとの GitHub の説明と注意

Merge commit: 既定の Merge pull request を押すと、ブランチの全コミットが、マージコミットで base branch に入ります。--no-ff のオプションで（fast-forward せずに）マージされます。fast-forward は、枝分かれしていない履歴を、ただ先へ進めるだけの合流のしかたです。

Squash and merge: プルリクエストのコミットを 1 つにまとめて、既定のブランチに入れます（fast-forward のオプションで）。作業途中のコミットを履歴に残さず、すっきりさせられます。GitHub が既定のコミットメッセージを作り、それを編集できます。使うには、リポジトリで squash が許されている必要があります。公式が挙げる注意は、次の 3 つです（About merge methods on GitHub）。

元の変更がいつ、誰のものだったかの情報が失われる
squash してマージしたあとも同じ head branch で作業を続け、同じブランチどうしで新しいプルリクエストを作ると、前に squash したコミットがまた並びます。同じコンフリクトを、何度も解くことがあります
元のコミットの SHA が失われる

squash は、短く使うブランチに向きます。長く使うブランチは、マージコミットにするか、次のプルリクエストの前にリベースする、と公式は書いています。

Rebase and merge: ブランチの各コミットを、マージコミットなしで 1 つずつ base branch に足します。fast-forward のように一直線の履歴になりますが、新しいコミットで履歴を書き直して、それを実現しています。GitHub の Rebase and merge は、手元の git rebase と少し違います。GitHub では、いつもコミッターの情報が更新され、新しいコミットの SHA になります。手元の git rebase は、祖先のコミットの上でリベースするときにコミッターの情報を変えません。また、最初から空のコミット（git commit --allow-empty で作ったものなど）は落とされます。

Rebase and merge の注意として、公式は次の 2 点を挙げています。

使う前に、貢献者が手元でリベースしてコンフリクトを解き、プルリクエストのブランチへ強制 push（force push）しなければならないことがあります。強制 push は、ほかの人がその上に積んだ作業を上書きしないよう、慎重に行います
Rebase and merge で入るコミットは、コミットの署名の検証なしで base branch に入ります

どの方式が使えるかはリポジトリの設定しだい

どの方式が使えるかは、リポジトリの設定で決まります。使いたい方式だけを有効にすれば、方式を 1 つに決められます。マージキューを使うブランチでは、方式をキューが決めるので、自分で選べません。

画面でマージする

画面でのマージの手順です（Merging a pull request）。ボタンの名前は、このページ（英語版）の表記です。

リポジトリ名の下の Pull requests から、マージしたいプルリクエストを開きます。
プルリクエストのいちばん下までスクロールします。
リポジトリで有効になっている方式から、1 つ選びます。Merge commit は Merge pull request をクリックします（表示されていなければ、マージのメニューから Create a merge commit を選びます）。squash は、メニューから Squash and merge を選んでから、Squash and merge をクリックします。rebase は、メニューから Rebase and merge を選んでから、Rebase and merge をクリックします。
求められたら、コミットメッセージを書きます（既定のままでもかまいません）。
Confirm merge・Confirm squash and merge・Confirm rebase and merge のどれかをクリックします。
必要なら、ブランチを消します。ブランチの一覧がすっきりします。

下書きのプルリクエストは、マージできません。リポジトリのルールや保護ブランチで、マージの前にレビュー、ステータスチェック、最新のブランチが求められることもあります。条件がそろったら自動でマージする設定もあります。リポジトリの設定によっては、マージのあと head branch が自動で消えます。マージ済みのプルリクエストの head branch を消すと、そのブランチを base にしていた、同じリポジトリの開いているプルリクエストは、base が自動で付け替えられます。

gh でマージする

gh pr merge でもマージできます。番号・URL・ブランチの名前のどれかで、プルリクエストを指定します。方式のフラグを付けないと、対話で方式を選びます。

gh pr merge 523 --squash --delete-branch

方式は、-m（--merge）、-s（--squash）、-r（--rebase）で指定します。-d（--delete-branch）を付けると、マージのあと、手元とリモートのブランチを消します。公式の例には --body "my squash commit" を付けたものもあります。gh の説明では、--body は "Body text for the merge commit"（マージ用のコミットの本文）、題は別に -t（--subject）で指定します。--body の値が、できあがるコミットのどこに入るかは、確かめていません。

マージしないとき・取り消すときはどうする？

マージしないなら閉じる

マージしないプルリクエストは、閉じます。プルリクエストのいちばん下、コメント欄の下にある Close pull request をクリックします。必要なら、ブランチを消します。gh では gh pr close 番号 です。-d（--delete-branch）でブランチも消し、-c（--comment）で閉じるときのコメントを残せます。

base branch を間違えて開いただけなら、閉じて作り直さなくても、base branch を変えられます（Closing a pull request）。

マージしたあとに取り消す

マージ済みのプルリクエストを取り消すには、プルリクエストのいちばん下近くにある Revert をクリックします。元のマージコミットを打ち消す、新しいプルリクエストができるので、それをマージします。書き込み権限が必要です。Revert が出ていなければ、リポジトリの管理者に権限を頼みます。コンフリクトになるときや、GitHub でマージしていないときは、コミットを 1 つずつ git revert する必要があることがあります（Reverting a pull request）。

コンフリクトのときや、手元で動かしたいとき

コンフリクト（同じ場所を別々に変えてしまい、自動では合流できない状態）があるときや、先に動かして確かめたいときは、プルリクエストを手元にチェックアウトします。gh では、gh pr checkout に番号・URL・ブランチの名前のどれかを渡します（別名は gh pr co です）。

gh pr checkout 123

GitLab の「マージリクエスト」とは何が違う？

GitLab では、コードのレビュー・話し合い・変更の追跡をまとめて行う場所を、merge request（マージリクエスト） と呼びます（GitLab Docs）。GitLab の日本語版の文書も、「マージリクエスト」と書いています。

同じものかどうかについては、GitLab 社の移行ツール（Congregate）の用語表が、GitLab の Merge Request と GitHub の Pull Request を「同じ働きで、名前が違う」（"Same function, different name"）と並べています（用語表）。ただし、これは docs.gitlab.com の文書ではなく GitLab 社のリポジトリにある文書で、日付は確かめられませんでした。docs.gitlab.com の merge request と GitHub からの移行の文書には、同じものと言い切る文は見つかりませんでした（2026年10月時点）。GitLab の「GitHub から移行する」の文書は、GitHub の Pull requests を取り込む項目に挙げています。

名前のほかに、公式の文書から確かめられる違いを表にします。

項目	GitHub のプルリクエスト	GitLab のマージリクエスト
番号の書き方	Issue にもプルリクエストにも `#` を使う	Issue には `#`、merge request には `!` を使う
下書き	下書きのプルリクエストはマージできない	Draft の merge request は、ほかのマージの条件を満たしていてもマージできない。題の頭に `Draft:` などを付けるか、Mark as draft を選ぶ
マージの方式	プルリクエストをマージするときに、リポジトリが許した方式から選ぶ	プロジェクトの設定（Settings の Merge requests）で、Merge commit・Merge commit with semi-linear history・Fast-forward merge から選ぶ。squash は別の設定
squash したときのコミット	1 つにまとめて、fast-forward で入る	fast-forward merge にしていなければ、squash のコミットとマージコミットで、最大 2 つ
Request changes	ルールが無ければ、マージを止めない	作者が対応するまで、マージを止める

同じ名前のボタンでも、Request changes の効き方は違います。GitHub では、ルールを設定していなければ情報として伝えるだけで、ルールがあるときはマージが止まりますが、GitLab では、作者が指摘に対応するまでマージを止めます（GitLab のレビューの文書）。GitLab では、merge request に Assignee（持ち主で、進み具合に責任を持つ人。ふつうは作者）と Reviewer（変更をレビューする人）の 2 つの役があります。

よくある質問

プルリクエストと push の違いは？

push は、コミットした変更をリモートリポジトリに送ることです。プルリクエストは、push したブランチの変更を、別のブランチに取り込んでもらうための提案です。プルリクエストを出す前に、ブランチを push しておきます。くわしくは、前の「プルリクエストとは？push との違いは？」を見てください。

「There isn't anything to compare.」と出て、プルリクエストを作れないときは？

この文面の意味を説明した GitHub の公式の文書は、見つかりませんでした。そのため、原因は断定できません。公式の文書から確かめられるのは、次の 3 点です。

プルリクエストは、head branch の変更を base branch と比べます
プルリクエストは、2 つの異なるブランチの間でしか開けません
変更をコミットして、ブランチを push してから出します

base と compare に選んだブランチが、意図したものか見直す手がかりになります。

出したあとに直したいとき、出し直す必要はある？

出し直す必要はありません。同じブランチ（head branch）にコミットを足して push すれば、自動でそのプルリクエストに加わります。直す間は、下書きに戻しておくこともできます。指摘への対応のしかたは、前の「指摘に対応する」を見てください。

プルリクエストを取り消すには？

マージする前なら、プルリクエストを閉じます（Close pull request）。直す間だけなら、下書きに戻す方法もあります。マージしたあとなら、Revert で、元のマージコミットを打ち消す新しいプルリクエストを作ります。くわしくは、前の「マージしないとき・取り消すときはどうする？」を見てください。

プルリクエストのテンプレートは作れる？

作れます。リポジトリに pull_request_template.md（リポジトリの直下）、docs/pull_request_template.md、.github/pull_request_template.md のどれかを置くと、プルリクエストの本文に、その中身が自動で入ります。gh pr create では、-T（--template）でテンプレートのファイルを指定できます。

まとめ

プルリクエストは、あるブランチの変更を別のブランチにマージすることを提案する、GitHub の機能です。push は送るだけで、プルリクエストは取り込んでもらうための提案です。
作る前に、ブランチを作って、小さくコミットして、push しておきます。書き込み権限が無いときは、先にリポジトリをフォークします。作るのは、画面の Compare & pull request か、gh pr create です。作業中なら、下書き（draft）にできます。
レビューの選択肢は、Comment・Approve・Request changes の 3 つです。Request changes は、ルールを設定していなければ、それだけではマージを止めません。承認として記録されるのは、Approve を選んだレビューです。
マージの方式は、Merge commit（履歴を全部残す）、Squash and merge（1 つのコミットにまとめる）、Rebase and merge（一直線にする。いつも新しい SHA になる）の 3 つです。使える方式はリポジトリの設定しだいです。
マージしないなら Close pull request で閉じます。マージしたあとは Revert で打ち消します。
GitLab のマージリクエストは、Request changes がマージを止めるなど、細かい動きが違います。docs.gitlab.com の merge request と GitHub からの移行の文書には、同じものと言い切る文は見つかりませんでした（GitLab 社の移行ツールの用語表は「同じ働き」と並べています。2026年10月時点）。
GitHub Docs の日本語版は、ボタンの名前や訳が、ページによって揺れています。この記事の手順と注意は、英語版にもとづいています。