はじめに
この記事では、作業ブランチで行った変更をGitHub上でPull Request（PR）を作成し、mainブランチへマージするまでの手順を説明します。
Gitの運用では、mainブランチへ直接pushせず、必ずPRを経由して変更を取り込むことが一般的です。PRを使うことで、変更内容・動作確認・履歴がGitHub上に記録され、mainを安全な状態に保てます。
前提
- GitHubリポジトリは作成済み
- ローカルで作業ブランチを作成済み
- 作業ブランチでコミット済み
- これから作業ブランチをGitHubへpushする
-
mainへ直接pushせず、PR経由で取り込む運用
この記事での例：
| 項目 | ブランチ名 |
|---|---|
| 作業ブランチ | chore/setup-laravel |
| マージ先 | main |
全体フロー
- 作業ブランチをGitHubへpush
- GitHubでPRを作成する
- PRの内容・コンフリクト有無を確認する
- PRを
mainへマージする - GitHub上の作業ブランチを削除する
- ローカルの
mainを最新化する - ローカルの作業ブランチを削除する
- リモート追跡ブランチを整理する
- 最終確認
※ 手順3でコンフリクトが発生した場合は、後述の「コンフリクトした場合」の手順で解消してから手順4へ進みます。
Pull Requestとは
Pull Request（PR）とは、作業ブランチで行った変更をmainなどのブランチに取り込んでよいかを確認・依頼する仕組みです。
PRを作成すると、変更内容・動作確認・確認結果をGitHub上に残せます。チーム開発ではレビューの場として使われ、個人開発でも変更履歴の管理に役立ちます。
1. 作業ブランチをGitHubへpushする
まず、作業ツリーがcleanな状態であることを確認します。
git status
nothing to commit, working tree cleanと表示されていれば、コミット漏れはありません。
次に、作業ブランチをGitHubへpushします。
git push -u origin chore/setup-laravel
-uオプションは、ローカルブランチとリモートブランチを紐付けるためのものです。初回pushの際に指定します。
2. GitHubでPRを作成する
GitHubのリポジトリページを開くと、pushした直後は以下のような通知が表示されます。
chore/setup-laravel had recent pushes [Compare & pull request]
「Compare & pull request」 ボタンを押してPR作成画面へ進みます。
base と compare を確認する
PR作成画面の上部に、以下のようなブランチ選択が表示されます。
base: main <- compare: chore/setup-laravel
| 項目 | 意味 |
|---|---|
base |
変更を取り込む先のブランチ（マージ先） |
compare |
変更を取り込む元のブランチ（作業ブランチ） |
baseとcompareを逆にするとmainの変更を作業ブランチへ取り込む操作になってしまうため、必ず確認してください。
3. PRタイトルと本文を書く
PRタイトル例
chore: Laravel初期環境を構築
PR本文例
## 内容
- Laravel 10プロジェクトを作成
- Laravel Sailを設定
- Web / MySQL / phpMyAdmin のポート設定を追加
- phpMyAdminを追加
- SailのPHPバージョンを8.2に固定
- Breeze認証機能を追加
- timezone / locale / faker_locale を日本向けに設定
- Breeze日本語化を追加
- Laravel IDE Helperを導入
- Larastanを導入
## 動作確認
- `./vendor/bin/sail ps`
- `./vendor/bin/sail test`
- `./vendor/bin/sail npm run build`
- `./vendor/bin/phpstan analyse`
## 確認結果
- Laravel: http://localhost:82 表示OK
- phpMyAdmin: http://localhost:8083 表示OK
- MySQL: healthy
- PHPUnit: 25 passed
- Vite build: 成功
- PHPStan: No errors
- `git status`: clean
PR本文に「何をしたか」「どう確認したか」「結果はどうだったか」を書いておくと、後から変更の経緯を追いやすくなります。個人開発でも、作業ログとして役立ちます。
内容を確認したら 「Create pull request」 を押してPRを作成します。
4. PR作成後に確認すること
PRを作成すると、PR画面に以下のような表示が出ます。
This branch has no conflicts with the base branch.
Merging can be performed automatically.
| 表示 | 意味 |
|---|---|
| No conflicts with base branch |
mainと作業ブランチの間でコンフリクト（競合）が発生していない |
| Merging can be performed automatically | 自動でマージを実行できる状態 |
コンフリクトが発生している場合はマージ前に解消が必要です。コンフリクトがない状態を確認してからマージに進みます。
5. PRをmainへマージする
Merge pull request
PR画面下部の 「Merge pull request」 ボタンを押します。押すと、マージコミットのメッセージを入力するフォームが展開されます。デフォルトのメッセージのまま進めて問題ありません。
Confirm merge
「Confirm merge」 を押すと、マージが実行されます。
マージが完了すると、以下のメッセージが表示されます。
Pull request successfully merged and closed
この表示が出ればマージは完了です。
6. Add a comment について
PR画面には 「Add a comment」 という入力欄があります。これはPRに対してコメントを残すための欄です。
レビューコメントや補足事項を残す場合に使いますが、マージ操作自体には関係しません。今回のような個人開発の手順では、特に入力は必要ありません。
7. GitHub上の作業ブランチを削除する
マージが完了すると、PR画面に 「Delete branch」 ボタンが表示されます。
このボタンを押すと、GitHub上（リモート）の作業ブランチが削除されます。mainへのマージが済んだブランチは不要なため、削除してリポジトリをきれいに保ちます。
注意：この操作はGitHub上のリモートブランチを削除するだけです。ローカルの作業ブランチは別途削除する必要があります（手順9で説明します）。
8. ローカルmainを最新化する
ローカルのmainブランチに切り替え、GitHubへマージされた変更を取り込みます。
git switch main
git pull origin main
git pull origin mainを実行することで、GitHub上のmainの状態がローカルに反映されます。マージ後にこの操作を行わないと、ローカルのmainが古いままになるため、必ず実行してください。
9. ローカルの作業ブランチを削除する
ローカルの作業ブランチを削除します。
git branch -d chore/setup-laravel
-dオプションは、マージ済みのブランチのみ削除できる安全なオプションです。マージされていないブランチを誤って削除しようとした場合はエラーになります。
削除後、ブランチ一覧を確認します。
git branch
chore/setup-laravel が一覧から消えていればOKです。
GitHub側のブランチ削除（手順7）とローカルブランチ削除（この手順）は別の操作です。どちらか一方だけでは、もう一方には影響しません。
10. リモート追跡ブランチを整理する
GitHub上で作業ブランチを削除しても、ローカルの git branch -r に古いリモート追跡ブランチが残ることがあります。
たとえば、GitHub上では chore/setup-laravel を削除済みなのに、ローカルで以下のように表示される場合があります。
git branch -r
origin/chore/setup-laravel
origin/main
この状態でリモートブランチを削除しようとしても、GitHub上にはすでに存在しないため、以下のようなエラーになります。
git push origin --delete chore/setup-laravel
error: unable to delete 'chore/setup-laravel': remote ref does not exist
error: failed to push some refs to 'github.com:ユーザー名/リポジトリ名.git'
この場合、GitHub上のブランチはすでに削除済みで、ローカルに古いリモート追跡情報だけが残っている状態です。
古いリモート追跡ブランチ情報は、以下のコマンドで整理できます。
git fetch --prune
実行例：
From github.com:ユーザー名/リポジトリ名
- [deleted] (none) -> origin/chore/setup-laravel
最後に確認します。
git branch -r
origin/main
origin/main だけになっていれば、不要なリモート追跡ブランチ情報は整理できています。
補足
git branch -r に表示されるのは、GitHub上の現在のブランチ一覧そのものではなく、ローカルが持っているリモート追跡ブランチ情報です。
そのため、GitHub上でブランチを削除しても、ローカル側の情報が古いまま残ることがあります。
その場合は git fetch --prune で整理します。
11. 最終確認
最後に作業ツリーの状態を確認します。
git status
On branch main
nothing to commit, working tree clean
この表示が出れば、すべての手順が完了しています。
コンフリクトした場合
PR画面でコンフリクトが表示された場合は、ローカルの作業ブランチにmainの最新状態を取り込み、衝突箇所を修正して再pushします。
1. 作業ブランチにいるか確認する
git branch
* chore/setup-laravelになっていればOKです。違う場合は切り替えます。
git switch chore/setup-laravel
2. GitHubの最新状態を取得して、作業ブランチに取り込む
git fetch origin
git merge origin/main
衝突があると、Gitが止まって以下のように表示されます。
CONFLICT (content): Merge conflict in resources/views/welcome.blade.php
Automatic merge failed; fix conflicts and then commit the result.
3. コンフリクトしているファイルを確認する
git status
both modified: と表示されているファイルがコンフリクト箇所です。
4. ファイルを開いて衝突箇所を修正する
コンフリクトしたファイルには以下の印が入ります。
<<<<<<< HEAD
作業ブランチ側の内容
=======
main側の内容
>>>>>>> origin/main
| 印 | 意味 |
|---|---|
<<<<<<< HEAD から ======= まで |
現在の作業ブランチ側の内容 |
======= から >>>>>>> origin/main まで |
取り込もうとしているmain側の内容 |
必要な方を残す、または両方を組み合わせて正しいコードにします。修正後は<<<<<<< ======= >>>>>>>の印をすべて削除します。
5. 動作確認後にコミットしてpushする
修正後は動作確認を行います。
./vendor/bin/sail test
./vendor/bin/sail npm run build
./vendor/bin/phpstan analyse
問題なければステージングしてコミットします。
git add resources/views/welcome.blade.php
git status
git commit
git push
git addには修正したファイルを指定します。git statusで対象ファイルを確認してからコミットすると安全です。
git commitを実行するとエディタが開きます。Gitが用意したマージコミットメッセージのまま保存して閉じればOKです。
修正対象が複数あり、内容を確認済みであればgit add .でまとめてステージングしても構いません。
GitHub上のPR画面でNo conflicts with base branchと表示されれば、コンフリクト解消完了です。通常通りMerge pull requestへ進めます。
よくある注意点
-
baseとcompareを逆にしない（baseがマージ先） -
mainへ直接pushせず、必ずPR経由で取り込む - 少なくともマージ前には動作確認を済ませておく
- マージ後はローカルで
git pull origin mainを実行してmainを最新化する - GitHub側のブランチ削除とローカルブランチ削除は別の操作
-
git branch -dはマージ済みのブランチのみ削除できる（未マージブランチの誤削除を防げる） - GitHub上でブランチを削除しても、
git branch -rに古いリモート追跡ブランチが残ることがある -
remote ref does not existが出た場合は、GitHub上には存在せず、ローカルの追跡情報だけが残っている可能性がある - 古いリモート追跡情報は
git fetch --pruneで整理できる
まとめ
PRを使った運用では、作業内容・動作確認・確認結果がGitHub上に記録として残ります。mainブランチへ直接pushする運用に比べて、変更の経緯を追いやすく、誤った変更がmainに混入するリスクを減らせます。
個人開発であっても、PR経由でマージする習慣をつけておくと、チーム開発へのスムーズな移行にもつながります。