GitHubのブランチとPull Requestとは？初心者向けに流れと使い方を実例で解説

GitやGitHubを使い始めると、次に出てくるのが「ブランチ」と「Pull Request」です。

「mainブランチを直接編集してはいけないと言われた」
「Pull Requestを作ってと言われたけれど、何をすればいいのか分からない」

最初はこの2つの関係が分かりにくいかもしれません。

ブランチとPull Requestは、簡単にいうと、

本番のコードを直接変更せず、別の場所で作業して、内容を確認してから反映するための仕組み

です。

この記事では、GitHub初心者向けに、

• ブランチとは何か
• Pull Requestとは何か
• mainブランチを直接変更しない理由
• 新しいブランチを作る方法
• 変更をcommitしてGitHubへpushする方法
• Pull Requestを作る方法
• レビュー後にmergeする流れ
• 初心者が間違えやすいポイント

までを、実際の操作順に沿って解説します。

ブランチとは

ブランチは、Gitで作業を分けるための仕組みです。

たとえば、現在のmainブランチに正常に動いているコードがあるとします。

そこへ新しい機能を追加したい場合、mainを直接変更すると、作業途中のコードや不具合のあるコードまでmainへ入ってしまう可能性があります。

そこで、作業用のブランチを作ります。

イメージすると、

main
│
├─ 現在正常に動いている状態
│
└─ feature/login
   └─ ログイン機能を作業中

という状態です。

feature/login 側で作業している間は、main側の履歴とは分けて変更を進められます。

作業が完成したら、その変更をmainへ反映します。

なぜmainブランチを直接変更しないのか

1人で小さな練習用リポジトリを使うだけなら、mainを直接変更しても大きな問題にならないことがあります。

しかし、チーム開発ではmainを直接変更しない運用がよく使われます。

理由は、変更内容を確認する機会を作れるからです。

たとえば、

main
↓
直接変更
↓
すぐ本線へ反映

では、間違った変更もそのまま入ってしまいます。

一方、

main
↓
作業用ブランチを作成
↓
変更
↓
Pull Request
↓
レビュー
↓
問題なければmainへ反映

という流れなら、mainへ入れる前に内容を確認できます。

つまりブランチは、

安全に作業する場所

Pull Requestは、

その変更をmainへ入れてよいか確認する場所

と考えると分かりやすくなります。

Pull Requestとは

Pull Requestは、あるブランチの変更を別のブランチへ反映したいときに使うGitHubの機能です。

よくあるのは、

作業ブランチ
↓
Pull Request
↓
main

という流れです。

Pull Requestを作ると、GitHub上で、

• 何を変更したのか
• どのファイルが変わったのか
• どんなcommitが含まれているのか
• 自動テストが成功しているか
• レビューでどんな指摘があったか

などを確認できます。

単なる「mainへ入れてください」という申請ではなく、変更内容をまとめて確認・相談する場所と考えると理解しやすいです。

今回試す流れ

今回は、次の流れを実際に試します。

main
↓
作業用ブランチを作る
↓
ファイルを変更する
↓
git status
↓
git add
↓
git commit
↓
GitHubへpush
↓
Pull Requestを作る
↓
変更内容を確認
↓
merge

Gitの基本操作にまだ慣れていない場合は、まず git status、git add、git commit の役割を理解してから進めると分かりやすくなります。

作業前に現在のブランチを確認する

まず、現在どのブランチにいるのか確認します。

git branch

現在のブランチには * が付きます。

たとえば、

* main

と表示されていれば、現在はmainブランチにいます。

作業を始める前に、

今どのブランチにいるのか

を確認する習慣を付けておくと、別のブランチを間違えて編集する事故を減らせます。

新しいブランチを作る

今回は、

feature/add-message

というブランチを作ります。

次のコマンドを実行します。

git switch -c feature/add-message

-c を付けると、新しいブランチを作成して、そのブランチへ切り替えます。

もう一度、

git branch

を実行します。

  main
* feature/add-message

のようになっていれば、作業用ブランチへ切り替わっています。

ブランチ名は何でもいいのか

Gitの仕組みとしては自由に名前を付けられますが、何の作業か分かる名前にした方が管理しやすくなります。

たとえば、

feature/login
feature/add-search
fix/header-layout
fix/login-error
docs/update-readme

のような名前です。

ただし、feature/ や fix/ などの命名ルールは絶対ではありません。

チームに既存ルールがある場合は、そのルールを優先してください。

重要なのは、

ブランチ名を見て何の作業なのか分かること

です。

作業用ブランチでファイルを変更する

今回は例として README.md に次の1行を追加したとします。

ブランチとPull Requestを練習しています。

保存したら、

git status

を実行します。

変更されたファイルとして README.md が表示されれば、Gitが変更を認識しています。

ここでもすぐcommitするのではなく、

何を変更した状態なのか確認する

ことが大切です。

変更をcommitする

まず、変更をステージングします。

git add README.md

次に、

git status

を確認します。

問題なければcommitします。

git commit -m "READMEにブランチ練習文を追加"

これで変更が作業ブランチの履歴へ記録されます。

この時点では、まだGitHub上のブランチには反映されていません。

GitHubへブランチをpushする

ローカルで作ったブランチをGitHubへ送ります。

初回は次のように実行できます。

git push -u origin feature/add-message

origin は、通常GitHub上のリモートリポジトリを表します。

-u を付けて上流ブランチを設定すると、その後は状況によって、

git push

だけで送れるようになります。

pushが成功したらGitHubのリポジトリを開きます。

Pull Requestを作る

GitHubへ作業ブランチをpushすると、リポジトリ画面に、

Compare & pull request

といった案内が表示されることがあります。

そこからPull Requestを作成できます。

表示されない場合は、

Pull requests
↓
New pull request

から作成できます。

ここで重要なのが、

base

と、

compare

です。

今回なら、

base: main
compare: feature/add-message

にします。

これは、

feature/add-messageの変更をmainへ入れたい

という意味です。

逆にすると意図したPull Requestにならないので、作成前に確認してください。

Pull Requestのタイトルを書く

Pull Requestのタイトルには、何を変更したのか分かる内容を書きます。

たとえば、

READMEにGit練習用の説明を追加

のようなタイトルです。

修正
変更しました
対応

だけでは、一覧から見たときに何のPull Requestなのか分かりません。

短くてもよいので、変更内容が分かるタイトルにします。

Pull Requestの説明に何を書くか

Pull Request本文には、最低限、

• 何を変更したか
• なぜ変更したか
• どのように確認したか

を書いておくとレビューしやすくなります。

たとえば、

## 変更内容

READMEにブランチとPull Requestの練習用文章を追加しました。

## 目的

GitHubのブランチ操作を確認するためです。

## 確認内容

READMEの表示に問題がないことを確認しました。

という形です。

実務ではさらに、

• 関連Issue
• レビューしてほしい場所
• テスト結果
• 影響範囲
• スクリーンショット

などを追加することもあります。

最初から長文を書く必要はありません。

レビューする人が何を確認すればよいか分かること

を意識します。

Pull Requestを作ったらFiles changedを見る

Pull Requestを作成したら、まず変更差分を確認します。

GitHubのPull Requestには、変更されたファイルを確認する画面があります。

ここで、

削除するつもりがない行を消していないか
余計なファイルを変更していないか
デバッグ用の文字が残っていないか
秘密情報が含まれていないか

などを確認します。

Pull Requestは他人にレビューしてもらうためだけのものではありません。

自分自身で変更を見直す場所

としても非常に役立ちます。

Pull Requestを作ったあとに修正が必要になったら

Pull Requestを作ったあとで、

「誤字があった」

「レビューで修正を依頼された」

という場合があります。

Pull Requestを閉じて作り直す必要はありません。

同じ作業ブランチで修正し、

git add .

git commit -m "レビュー指摘を修正"

git push

と追加でpushすれば、そのcommitが同じPull Requestへ追加されます。

つまりPull Requestは、

作成
↓
レビュー
↓
修正
↓
追加push
↓
再確認

という流れで育てていくことができます。

レビューでは何を見るのか

チーム開発では、Pull Requestを他のメンバーがレビューすることがあります。

レビューでは、単にコードが動くかだけではなく、

• 意図した変更になっているか
• 既存機能を壊していないか
• 不要な変更が混ざっていないか
• 読みやすいコードか
• セキュリティ上の問題がないか
• テストが必要ではないか

などを確認します。

GitHubでは変更行ごとにコメントを付けることもできます。

修正が必要なら、作業ブランチへ変更を追加して再度pushします。

GitHub Actionsがある場合はChecksも確認する

リポジトリでGitHub Actionsが設定されている場合、Pull Requestに対して自動テストなどを実行できます。

その場合は、レビューだけでなく自動チェックの結果も確認します。

イメージすると、

作業ブランチ
↓
Pull Request
↓
コードレビュー
＋
自動テスト
↓
両方問題なし
↓
merge

となります。

人による確認と自動テストを組み合わせることで、mainへ問題のある変更を入れる可能性を減らせます。

問題なければmergeする

変更内容の確認やレビューが終わり、問題がなければPull Requestをmergeします。

mergeすると、

feature/add-message

にあった変更が、

main

へ統合されます。

GitHubではリポジトリの設定によって複数のmerge方法が選べる場合があります。

初心者のうちは、チームで指定されている方法があるならそれに従ってください。

大切なのは、

レビューや必要なチェックが終わる前に、急いでmergeしないこと

です。

merge後のブランチはどうする？

作業が完了し、mainへmergeしたブランチは不要になることがあります。

GitHub上ではPull Requestをmergeしたあとに、ブランチを削除できる場合があります。

ローカル側でも、不要になったブランチは整理できます。

ただし、

まだ作業が残っているブランチを間違えて削除しない

ように注意してください。

初心者のうちは、削除前にPull Requestがmerge済みかを確認してから操作する方が安全です。

よくある間違い1：mainで作業してしまった

作業を始めたあとに、

「ブランチを作るのを忘れてmainを編集していた」

と気づくことがあります。

この場合、焦って変更を消す必要はありません。

まず、

git status

を確認します。

まだcommitしていない変更であれば、状況によってはその変更を保持したまま新しいブランチへ切り替えられることもあります。

ただし、変更内容やブランチ間の差によって操作結果が変わるため、

よく分からない状態で reset --hard などを実行しない

ことが重要です。

まず現在の状態を確認してから対処します。

よくある間違い2：別のブランチで作業していた

作業前に、

git branch

または、

git status

を確認しておくと防ぎやすくなります。

「何を変更するか」だけでなく、

どのブランチを変更しているか

もGitでは重要です。

作業開始時の確認を習慣にしましょう。

よくある間違い3：baseとcompareを逆にする

Pull Request作成画面では、

base: main
compare: feature/add-message

のように表示されます。

今回の目的は、

feature/add-message
↓
main

なので、baseがmainです。

作成前に、

どこから、どこへ変更を入れようとしているのか

を確認してください。

よくある間違い4：関係ない変更までPull Requestに入っている

Pull Requestを開いたら、Files changedで差分を確認します。

本来READMEだけを変更したはずなのに、

設定ファイル
一時ファイル
別機能のコード

まで入っているなら、作業の切り分けができていない可能性があります。

Pull Requestは小さく、目的を絞った方がレビューしやすくなります。

たとえば、

ログイン機能追加
＋
デザイン全面変更
＋
別のバグ修正

を1つのPull Requestにまとめるより、可能なら目的ごとに分けた方が変更内容を追いやすくなります。

コンフリクトとは

複数の人が同じ場所を変更すると、Gitが自動的にどちらを採用すればよいか判断できないことがあります。

これをコンフリクトと呼びます。

たとえば、

Aさん
READMEの1行目を変更

Bさん
同じREADMEの1行目を別の内容へ変更

という場合です。

Gitは、

「どちらの変更を残せばよいのか」

を自動では判断できません。

そのため、人間が内容を確認して解決する必要があります。

コンフリクトが発生したときも、焦って片方を全部削除するのではなく、

何と何が競合しているのか

を確認することが大切です。

ChatGPTなどのAIをPull Requestで使う場合

Pull Requestの説明文を作ったり、差分を整理したりするときにAIを使うこともできます。

たとえば、

以下のGit差分を確認して、
Pull Request用に

1. 変更内容
2. 変更理由
3. 影響範囲
4. 確認項目
5. レビューしてほしい点

に整理してください。

と依頼すると、説明文のたたき台を作りやすくなります。

ただし、AIが、

動作確認済み
テスト成功済み
問題なし

と書いたとしても、実際に確認していないならそのまま使ってはいけません。

Pull Requestには、実際に確認できた内容だけを書くことが重要です。

また、差分やログに、

• APIキー
• パスワード
• アクセストークン
• 社内情報

などが含まれていないか確認してからAIへ渡してください。

ブランチとPull Requestの関係を整理する

最後に、全体の流れを整理します。

main
↓
作業用ブランチを作る
↓
ファイルを変更する
↓
git status
↓
git add
↓
git commit
↓
git push
↓
Pull Requestを作る
↓
Files changedで差分確認
↓
レビュー・自動テスト
↓
必要なら修正して再push
↓
問題なければmerge

ブランチとPull Requestを別々に覚えるより、この一連の流れとして理解する方が分かりやすくなります。

まとめ｜Pull Requestは「変更を入れる前の確認場所」

ブランチは、mainなどの本線とは分けて安全に作業するために使います。

Pull Requestは、そのブランチで行った変更を、

本線へ反映してよいか確認するための場所

です。

初心者のうちは、次の流れだけ覚えておけば十分です。

ブランチを作る
↓
変更する
↓
commitする
↓
pushする
↓
Pull Requestを作る
↓
差分を見る
↓
レビューする
↓
mergeする

そして、作業を始める前には、

git status

や、

git branch

で現在の状態を確認する習慣を付けましょう。

GitHubを安全に使ううえで大切なのは、コマンドを大量に暗記することではありません。

今どのブランチにいて、何を変更し、それをどこへ反映しようとしているのか

を把握することです。

まずは練習用リポジトリで小さな変更を1つ作り、ブランチ作成からPull Requestのmergeまで一度通して体験してみてください。