はじめてのチーム開発！GitHubプルリクエスト入門

はじめに

はじめてチーム開発に参画するとき、こんな不安はありませんか？

• 「プルリクエストって聞いたことあるけど、実際どうやるの？」
• 「他の人のコードを壊してしまったらどうしよう...」
• 「レビューで怒られたらどうしよう...」

この記事を読めば、以下のことができるようになります：

• プルリクエストを作成してチームメンバーにレビューを依頼できる
• レビューコメントに適切に対応できる
• コンフリクトなどのトラブルに対処できる
• チーム開発の基本的なマナーを理解できる
• 自信を持ってチーム開発に参加できる

想定読者

• 個人でGitHubを使ったことがある
• git add、commit、pushなどの基本コマンドは知っている
• チーム開発は初めて、または始めたばかり

前提環境

• Git 2.x以上
• GitHub アカウント
• お好みのエディタ

プルリクエストとは？

個人開発との最大の違い

個人開発では、こんな感じでコードを更新していましたよね：

# 個人開発の場合
git add .
git commit -m "機能追加"
git push origin main  # 直接mainブランチにプッシュ！

でも、チーム開発では直接mainブランチにプッシュしません！

なぜプルリクエスト（PR）が必要？

プルリクエストは、いわば「コードの品質チェックゲート」です。

メリット：

1. バグの早期発見 - 他の人の目でチェック
2. 知識の共有 - チーム全体でコードを理解
3. 品質の担保 - 一定の基準を保てる

覚えておこう
プルリクエストは「お願い」です。「このコードをmainブランチに取り込んでもらえませんか？」という丁寧なお願いなのです。

実践！プルリクエストの作成手順

それでは、実際にプルリクエストを作成してみましょう！

ステップ1: ブランチを作成する

# 最新のmainブランチを取得
git checkout main
git pull origin main

# 新しいブランチを作成して移動
git checkout -b feature/add-user-profile
# または
git switch -c feature/add-user-profile  # Git 2.23以降

ブランチ名のコツ：

• feature/機能名 - 新機能追加
• fix/バグ名 - バグ修正
• docs/ドキュメント名 - ドキュメント更新

ステップ2: コードを変更してコミット

// user-profile.js
// ユーザープロフィール表示機能を追加
function displayUserProfile(user) {
    // ユーザー情報を表示する処理
    const profileElement = document.getElementById('profile');
    profileElement.innerHTML = `
        <h2>${user.name}</h2>
        <p>${user.bio}</p>
    `;
}

# 変更をステージング
git add user-profile.js

# コミット（メッセージは具体的に！）
git commit -m "feat: ユーザープロフィール表示機能を追加"

ステップ3: リモートにプッシュ

# 作成したブランチをリモートにプッシュ
git push origin feature/add-user-profile

初回プッシュ時は以下のようなメッセージが出ることがあります：

# こんなメッセージが出たら、表示されたコマンドをコピペ実行
fatal: The current branch feature/add-user-profile has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature/add-user-profile

ステップ4: GitHubでプルリクエストを作成

1. GitHubのリポジトリページを開く
2. 「Compare & pull request」ボタンをクリック（プッシュ直後なら表示される）
3. または「Pull requests」タブ → 「New pull request」

ステップ5: PR情報を記入

良いPRタイトルの例：

feat: ユーザープロフィール表示機能を追加 #123
fix: ログイン時のエラー処理を修正
docs: READMEにセットアップ手順を追加

PR説明文のテンプレート：

## 概要
ユーザープロフィール表示機能を実装しました。

## 変更内容
- プロフィール表示用のコンポーネントを追加
- APIからユーザー情報を取得する処理を実装
- スタイルの調整

## 動作確認
- [ ] ローカル環境で動作確認済み
- [ ] テストコードを追加/更新済み
- [ ] ドキュメントを更新済み

## スクリーンショット
（変更前後の画面キャプチャがあれば貼る）

## 関連Issue
close #123

レビューを受ける際のマナーとコツ

レビューコメントの種類を理解しよう

レビューコメントには主に3種類あります：

1. 必須対応（Request changes）

   このままだとバグが発生します。修正をお願いします。
   

2. 提案（Comment）

   こう書くともっと読みやすくなりますよ！
   

3. 質問

   この処理の意図を教えてもらえますか？
   

コメントへの対応方法

修正が必要な場合：

# 同じブランチで作業を続ける
git checkout feature/add-user-profile

# 修正を行う
# （エディタでコードを修正）

# 修正をコミット
git add .
git commit -m "fix: レビュー指摘事項を修正"

# プッシュ（PRは自動的に更新される）
git push origin feature/add-user-profile

GitHubでのコメント返信例：

# 良い返信例
修正しました！確認お願いします
コミット: abc123

# より丁寧な返信例
ご指摘ありがとうございます！
おっしゃる通り、エラーハンドリングが不足していました。
try-catchを追加して修正しました。

レビュー対応のベストプラクティス

1. 感謝の気持ちを忘れない

   • レビューは時間を使ってくれている
   • 「ありがとうございます」を言おう

2. 質問は積極的に

   この部分がよく理解できませんでした。
   もう少し詳しく教えていただけますか？
   

3. 議論は建設的に

   • 意見が分かれたら、理由を説明
   • 必要ならSlackやミーティングで相談

よくあるトラブルと解決方法

コンフリクトが発生した

他の人の変更と競合した場合の対処法：

# 1. 最新のmainを取得
git checkout main
git pull origin main

# 2. 自分のブランチに戻る
git checkout feature/add-user-profile

# 3. mainの内容をマージ
git merge main

# 4. コンフリクトを解消
# エディタで<<<< ==== >>>>の部分を手動で修正

# 5. 修正完了後
git add .
git commit -m "fix: mainブランチとのコンフリクトを解消"
git push origin feature/add-user-profile

間違えてコミットしてしまった

直前のコミットを修正したい場合：

# コミットメッセージだけ修正
git commit --amend -m "新しいコミットメッセージ"

# ファイルの修正も含める
git add forgotten-file.js
git commit --amend --no-edit

# 注意：push済みの場合は force push が必要
git push origin feature/add-user-profile --force-with-lease

プッシュできない

# エラー: rejected
# 原因：リモートに自分の知らない変更がある

# 解決方法
git pull origin feature/add-user-profile
# コンフリクトがあれば解消
git push origin feature/add-user-profile

チーム開発で気をつけたいベストプラクティス

コミットメッセージの書き方

# 良い例
feat: ユーザー認証機能を追加
fix: ログイン時のNullPointerExceptionを修正
docs: APIドキュメントを更新
refactor: 認証処理をリファクタリング

# 悪い例
修正
更新
WIP
あああ

Conventional Commitsを使おう：

• feat: 新機能
• fix: バグ修正
• docs: ドキュメント
• style: フォーマット修正
• refactor: リファクタリング
• test: テスト追加/修正
• chore: ビルドプロセスなど

手前味噌ですが、こちらも参考にしてください。

ブランチ戦略

main
  ├── develop
  │     ├── feature/user-auth
  │     ├── feature/payment
  │     └── fix/login-error
  └── hotfix/critical-bug

PRのサイズ

PRのサイズ	レビュー時間	品質
小さい（〜100行）	短い	高い
中くらい（〜500行）	普通	普通
大きい（500行〜）	長い	低い

Tips
PRは小さく、頻繁に！レビュアーの負担を減らそう

まとめ

プルリクエストは最初緊張するかもしれませんが、チーム開発の要です

最後に、失敗を恐れないでください！みんな最初は初心者でした。分からないことは積極的に質問して、チームと一緒に成長していきましょう！

参考リンク

• GitHub公式ドキュメント - プルリクエストについて
• Conventional Commits
• Git-flow ワークフロー
• 初心者向けGitコマンド一覧