← GitHubに戻る

GitHub Pull Request完全ガイド - レビュー、承認、マージまで

📅 2025-07-05
GitHub Pull Request コードレビュー チーム開発

Pull Requestとは

Pull Request（PR）は、コード変更をレビュー・議論してからメインブランチに統合する仕組みです。

Pull Requestの目的

  • 🔍 コードレビューで品質向上
  • 💬 変更内容の共有と議論
  • ✅ 自動テストの実行
  • 📚 変更履歴の記録
  • 🎓 チームメンバーの学習

良いPRの作り方

1. 適切なサイズ

  • ✅ 小さく、レビューしやすいPR（推奨: 200-400行）
  • ✅ 1つの機能・修正に集中
  • ⚠️ 大きすぎるPRは分割

2. わかりやすいタイトル

❌ 悪い例:
- Update code
- Fix
- WIP

✅ 良い例:
- feat: Add user authentication with JWT
- fix: Resolve null pointer in login handler
- refactor: Extract database logic to repository

3. 詳細な説明

## 変更内容
ユーザー認証機能を実装しました。

## 変更詳細
- JWT トークンベースの認証
- ログイン・ログアウトAPI
- ミドルウェアで認証チェック

## テスト方法
1. POST /api/login でログイン
2. トークンを取得
3. GET /api/profile にトークン付きでアクセス

## スクリーンショット
![login page](screenshot.png)

## チェックリスト
- [x] テストを追加
- [x] ドキュメント更新
- [x] エラーハンドリング実装
- [ ] パフォーマンステスト（TODO）

PRの作成手順

ステップ1: ブランチで開発

# 最新のmainから開始
git checkout main
git pull origin main

# フィーチャーブランチ作成
git checkout -b feature/user-auth

# 開発・コミット
git add .
git commit -m "feat: Add JWT authentication"

# プッシュ
git push origin feature/user-auth

ステップ2: GitHub でPR作成

1. リポジトリページを開く
2. 「Compare & pull request」ボタンをクリック
3. base: main ← compare: feature/user-auth を確認
4. タイトルと説明を記入
5. Reviewers を指定
6. Assignees を設定（自分）
7. Labels を追加（enhancement, bug, documentationなど）
8. Projects / Milestone を設定（任意）
9. 「Create pull request」をクリック

ステップ3: Draft PRの活用

まだレビュー不要な場合:

「Create draft pull request」を選択

- 途中経過の共有
- CI/CDテストの実行確認
- 早期フィードバックの獲得

準備ができたら「Ready for review」に変更

コードレビューの受け方

レビューコメントへの対応

レビュアーからコメントが来たら:

1. コメントを読んで理解
2. 必要に応じて議論
3. コードを修正
4. コミット・プッシュ

git add .
git commit -m "fix: Handle edge case in auth"
git push origin feature/user-auth

# PRに自動的に反映される

建設的なレスポンス

✅ 良い返答:
「ご指摘ありがとうございます。確かにエッジケースの
考慮が漏れていました。修正しました。」

「なるほど、その方法の方が読みやすいですね。
変更します。」

❌ 避けるべき返答:
「これで動くので問題ないです」
「時間がないので後で」

Suggestion機能の活用

レビュアーが提案したコードを直接適用可能:

1. Suggestionコメントを確認
2. 「Commit suggestion」をクリック
3. そのままコミットされる

レビュアーとして

効果的なレビュー観点

  • 機能性: 要件を満たしているか
  • バグ: エラーハンドリング、エッジケース
  • 可読性: 理解しやすいか
  • パフォーマンス: ボトルネックはないか
  • セキュリティ: 脆弱性はないか
  • テスト: 適切なテストがあるか

コメントの書き方

✅ 建設的なコメント:
「この部分、null チェックがないとエラーになりそうです。
`if (user) { ... }` を追加してはどうでしょうか？」

「ループの中で毎回DB接続しているので、
事前に接続を確立しては？」

❌ 避けるべきコメント:
「これはダメです」
「なぜこんなコードを書いたの？」

レビューステータス

Comment: コメントのみ（承認なし）
Approve: 承認（マージ可能）
Request changes: 修正が必要

自動化機能

GitHub Actions でCI/CD

# .github/workflows/pr-check.yml

name: PR Checks

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
      - run: npm test
      - run: npm run lint

Status Checksの必須化

Settings > Branches > Branch protection rules

✅ Require status checks to pass before merging
  - CI/CD Tests
  - Lint
  - Security Scan

自動コードフォーマット

# .github/workflows/format.yml

name: Auto Format

on:
  pull_request:
    branches: [main]

jobs:
  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm run format
      - uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: "style: Auto format code"

マージ方法

1. Create a merge commit

git merge --no-ff feature/user-auth

特徴:
- すべてのコミット履歴を保持
- マージコミットが作成される
- 誰が何をマージしたか明確

向いている:
- 履歴を完全に保持したい
- フィーチャーブランチの流れを残したい

2. Squash and merge（推奨）

複数のコミットを1つにまとめる

特徴:
- mainブランチがクリーン
- 小さいコミットを集約
- レビュー履歴は保持

向いている:
- クリーンな履歴が好み
- 開発中の細かいコミットを隠したい

3. Rebase and merge

コミットをmainの先頭に追加

特徴:
- 一直線の履歴
- マージコミット不要
- コミット順序が時系列

向いている:
- リニアな履歴が好み
- マージコミットを避けたい

PRテンプレートの設定

テンプレートファイルの作成

# .github/pull_request_template.md

## 📝 変更内容



## 🎯 目的



## 📋 変更詳細
- 
- 

## 🧪 テスト方法
1. 
2. 

## 📸 スクリーンショット



## ✅ チェックリスト
- [ ] テストを追加した
- [ ] ドキュメントを更新した
- [ ] エラーハンドリングを実装した
- [ ] パフォーマンスを考慮した
- [ ] セキュリティを考慮した

## 🔗 関連Issue
Closes #

## 💭 その他

便利な機能

ドラフトPR

用途:
- WIP（Work In Progress）の共有
- 早期フィードバック
- CI/CDテストの確認

作成方法:
「Create draft pull request」を選択

PR へのコメント記法

# コードブロック
```javascript
const user = getUser();
```

# リンク
See #123
Closes #456
Fixes #789

# メンション
@username レビューお願いします

# タスクリスト
- [x] 実装完了
- [ ] テスト追加

Co-authored-by

ペアプログラミング時:

git commit -m "feat: Add feature


Co-authored-by: Partner Name "

トラブルシューティング

コンフリクト発生時

1. ローカルで最新のmainをマージ
git checkout feature/my-feature
git fetch origin
git merge origin/main

2. コンフリクト解決
# ファイルを編集
git add .
git commit -m "Resolve merge conflicts"

3. プッシュ
git push origin feature/my-feature

PR が大きすぎる場合

1. 複数のPRに分割
  - PR1: データモデル
  - PR2: API実装
  - PR3: UI実装

2. または「stacked PR」
  base: main ← feature/step1
  base: feature/step1 ← feature/step2

CI/CD が失敗

1. Actions タブでログ確認
2. ローカルで同じコマンド実行
3. 修正してプッシュ
4. 自動的に再実行される

ベストプラクティス

1. 早めにPRを出す

  • Draft PR で早期フィードバック
  • 大きな手戻りを防ぐ

2. セルフレビューをする

PR作成後、自分で一度レビュー:
- Files changed タブで確認
- 不要なコメント削除
- デバッグコード削除

3. レビュアーの負担を減らす

  • 適切なサイズ
  • 詳細な説明
  • テスト済み

4. レビューは24時間以内

  • 迅速なフィードバック
  • 開発速度の維持

まとめ

効果的なPull Requestでコード品質とチームの生産性が向上します。

重要ポイント

  • 小さく、レビューしやすいPR
  • 詳細な説明とコンテキスト
  • 建設的なコードレビュー
  • 自動化でチェック
  • 迅速なフィードバック

次のステップ

  • GitHub Actions で高度な自動化
  • セマンティックバージョニング
  • リリースノート自動生成