GitHub初心者必見！プルリクエスト作成からマージまでの完全ガイド【2026年版】
Tech Trends AI
- 3 minutes read - 629 words目次
- プルリクエストとは？
- プルリクエストの基本的な流れ
- 事前準備：ブランチの作成と変更
- プルリクエストの作成手順
- レビューの依頼と管理
- レビューの実施方法
- マージの実行
- プルリクエストのベストプラクティス
- よくあるトラブルと対処法
- まとめ
プルリクエストとは？
プルリクエスト（Pull Request、PR） は、GitHubにおける協働開発の中核となる機能です。
基本概念
プルリクエストは、あなたが行った変更を他の開発者にレビューしてもらい、メインブランチ（通常はmainやmaster）に統合してもらうためのリクエストです。
個人ブランチ（feature/new-function） → メインブランチ（main）
↑
プルリクエスト
なぜプルリクエストが重要？
- コードレビュー: 他の人に変更をチェックしてもらえる
- 協働開発: チームメンバーと変更を共有できる
- 品質保証: バグや問題を事前に発見できる
- 変更履歴: どのような変更が行われたかが明確に残る
- 議論の場: 変更について議論やフィードバックができる
プルリクエストの基本的な流れ
プルリクエストの一般的なワークフローは以下の通りです：
graph LR
A[ブランチ作成] --> B[コード変更]
B --> C[コミット]
C --> D[プッシュ]
D --> E[PR作成]
E --> F[レビュー]
F --> G[修正・議論]
G --> H{承認?}
H -->|Yes| I[マージ]
H -->|No| G
I --> J[ブランチ削除]
事前準備：ブランチの作成と変更
プルリクエストを作成する前に、作業用のブランチを準備しましょう。
1. ブランチの作成
# 新しいブランチを作成して切り替え
git checkout -b feature/add-contact-form
# または最新のGitの場合
git switch -c feature/add-contact-form
2. 変更の実施とコミット
# ファイルを編集
echo "# 新機能の追加" > README.md
# 変更をステージング
git add .
# コミット
git commit -m "Add: 問い合わせフォーム機能の追加"
3. GitHubにプッシュ
# リモートリポジトリにプッシュ
git push origin feature/add-contact-form
プルリクエストの作成手順
ステップ 1: GitHubリポジトリページにアクセス
ブランチをプッシュすると、GitHubリポジトリのトップページに黄色いバナーが表示されます：
feature/add-contact-form had recent pushes 2 minutes ago
[Compare & pull request]
ステップ 2: プルリクエスト作成ページへ
「Compare & pull request」 ボタンをクリックするか、以下の手順で作成できます：
- 「Pull requests」 タブをクリック
- 「New pull request」 ボタンをクリック
- ベースブランチ（統合先）とコンペアブランチ（統合元）を選択
ステップ 3: プルリクエストの詳細入力
タイトル（必須）
明確で分かりやすいタイトルを入力します：
良い例：
Add: 問い合わせフォーム機能の追加Fix: ログイン時のエラー処理を修正Update: README.mdのセットアップ手順を更新
悪い例：
修正updateいろいろ変更
説明文（Description）
変更内容を詳しく説明します：
## 変更内容
- 問い合わせフォームを追加
- バリデーション機能を実装
- CSS スタイルを調整
## 変更理由
ユーザーからの問い合わせを受け付ける機能が必要になったため
## テスト内容
- [ ] フォームの入力チェック
- [ ] 送信機能の動作確認
- [ ] レスポンシブデザインの確認
## スクリーンショット
（変更前後の画面キャプチャがあれば添付）
## 関連Issue
Closes #123
ステップ 4: オプション設定
Reviewers（レビュアー）
レビューをお願いしたい人を選択します：
- 個人指名: 特定の専門知識を持つ人
- チーム指名: 関連するチーム全体
Assignees（担当者）
プルリクエストの責任者を設定（通常は作成者）
Labels（ラベル）
プルリクエストの分類に使用：
bug: バグ修正enhancement: 新機能documentation: ドキュメント関連urgent: 緊急
Projects（プロジェクト）
関連するプロジェクトボードがあれば関連付け
Milestone（マイルストーン）
特定のリリースやスプリントに関連付け
ステップ 5: プルリクエストの作成
「Create pull request」 ボタンをクリックして作成完了！
レビューの依頼と管理
レビュアーへの通知
プルリクエスト作成時に設定したレビュアーには自動で通知が送られます。
レビュー状態の確認
プルリクエストページで以下の状態を確認できます：
- 🟡 Review required: レビュー待ち
- ✅ Approved: 承認済み
- ❌ Changes requested: 修正要求あり
- 👁 Reviewed: レビュー済み（承認/却下なし）
レビューの追加依頼
新しいレビュアーを追加するには：
- 右サイドバーの 「Reviewers」 セクション
- ⚙️ アイコン をクリック
- 追加したいレビュアーを選択
レビューの実施方法
ファイル変更の確認
「Files changed」 タブで変更内容を確認します：
- 緑色（+）: 追加された行
- 赤色（-）: 削除された行
- グレー: 変更されていない行
インラインコメントの追加
特定の行にコメントするには：
- 該当行の 「+」 ボタンをクリック
- コメントを入力
- 「Start a review」 または 「Add review comment」 をクリック
レビューの種類
Comment（コメントのみ）
一般的なフィードバックや質問
この部分の処理について詳しく教えてください。
より効率的な書き方があるかもしれません。
Approve（承認）
変更内容に問題がなく、マージして良い状態
LGTM（Looks Good To Me）！
テストも通っており、実装も適切です。
Request changes（変更要求）
修正が必要な問題がある状態
セキュリティ上の問題があります。
以下の点を修正してください：
- XSS対策が不十分
- 入力値の検証を追加
レビュー送信
- 全てのコメントを入力完了
- 「Review changes」 ボタンをクリック
- レビューの種類を選択
- 全体的なコメントを追加（任意）
- 「Submit review」 をクリック
マージの実行
マージの条件確認
マージ前に以下を確認します：
- ✅ 必要なレビューが完了している
- ✅ CIテストが成功している
- ✅ コンフリクトが解決済み
- ✅ ブランチが最新状態
マージ方法の選択
GitHubでは3つのマージ方法があります：
1. Create a merge commit（マージコミット）
* マージコミット （M）
|\
| * 機能追加コミット （C）
| * 修正コミット （B）
|/
* メインブランチ （A）
使用場面: 機能ブランチの履歴を保持したい場合
2. Squash and merge（スカッシュマージ）
* 全変更をまとめた1つのコミット
|
* メインブランチ
使用場面: 複数の細かいコミットを1つにまとめたい場合
3. Rebase and merge（リベースマージ）
* 機能追加コミット （C）
* 修正コミット （B）
* メインブランチ （A）
使用場面: 線形な履歴を保ちたい場合
マージの実行手順
- 「Merge pull request」 ボタンをクリック
- マージ方法を選択（ドロップダウンから）
- 「Confirm merge」 をクリック
- 「Delete branch」 をクリック（任意）
マージ後の処理
# ローカルでメインブランチに切り替え
git checkout main
# 最新の変更を取得
git pull origin main
# 作業ブランチを削除（任意）
git branch -d feature/add-contact-form
プルリクエストのベストプラクティス
1. 適切なサイズ
- 小さく分割: 一度に大きすぎる変更をしない
- 単一責任: 1つのプルリクエストには1つの機能や修正
- 目安: 変更行数は300行以下が理想
2. 明確な説明
## 変更内容
具体的に何を変更したか
## 変更理由
なぜその変更が必要だったか
## 影響範囲
どの部分に影響するか
## テスト方法
どのようにテストすれば良いか
3. コミットメッセージ
# 良い例
git commit -m "Add: 問い合わせフォームのバリデーション機能"
git commit -m "Fix: ログイン失敗時のエラーメッセージ表示"
git commit -m "Update: README.mdのAPI仕様書リンク"
# 悪い例
git commit -m "修正"
git commit -m "update"
git commit -m "いろいろ"
4. 効果的なレビュー
レビュアーとして
- 建設的なフィードバック: 問題だけでなく改善案も提示
- 迅速な対応: 可能な限り早くレビューする
- 明確なコメント: 曖昧な表現を避ける
作者として
- レビューへの対応: コメントには必ず反応する
- 説明の追加: 必要に応じて追加情報を提供
- 感謝の表現: レビュアーへの感謝を忘れずに
5. CI/CDの活用
# .github/workflows/test.yml
name: Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run tests
run: npm test
よくあるトラブルと対処法
1. コンフリクト（競合）の解決
発生原因
他の人の変更と自分の変更が同じ部分で競合した場合
対処法
# メインブランチの最新を取得
git checkout main
git pull origin main
# 作業ブランチで最新をマージ
git checkout feature/add-contact-form
git merge main
# コンフリクトを手動で解決
# ファイルを編集して競合部分を修正
# 解決後にコミット
git add .
git commit -m "Resolve merge conflicts"
git push origin feature/add-contact-form
2. レビューの修正対応
修正コミットの追加
# 修正を実施
git add .
git commit -m "Fix: レビューフィードバック対応"
git push origin feature/add-contact-form
コミットの統合（推奨）
# 直前のコミットに修正を統合
git add .
git commit --amend --no-edit
git push --force-with-lease origin feature/add-contact-form
3. 間違ったブランチからプルリクエスト
問題
mainブランチから直接プルリクエストを作成してしまった
対処法
# 新しいブランチを作成
git checkout -b feature/correct-branch
# プルリクエストのベースブランチを変更
# GitHubのUI で「Edit」から変更可能
4. プルリクエストの取り下げ
手順
- プルリクエストページの 「Close pull request」
- ブランチを削除したい場合は 「Delete branch」
まとめ
プルリクエストは、現代のソフトウェア開発において欠かせない協働ツールです。
重要ポイント
- 計画性: 適切なサイズでブランチを分割
- 明確性: 分かりやすいタイトルと説明
- 迅速性: レビューと修正は素早く対応
- 協調性: チームメンバーとのコミュニケーションを大切に
継続的な改善
- 振り返り: プルリクエストプロセスを定期的に見直し
- ツール活用: テンプレートやCIツールの導入
- 学習: 他のプロジェクトの事例を参考に
プルリクエストをマスターすることで、より効率的で品質の高い開発が可能になります。最初は慣れないかもしれませんが、継続的に使用することで自然と身につけることができるでしょう。
次のステップ
- 実際にプルリクエストを作成してみる
- チームのレビュープロセスを確立する
- GitHubの高度な機能を学ぶ
- Draft プルリクエスト
- GitHub Actions との連携
- プルリクエストテンプレート
継続的な学習と実践により、あなたも優れた協働開発者になれるはずです！
PR
PR
