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


## はじめに

はじめてチーム開発に参画するとき、こんな不安はありませんか？
- 「プルリクエストって聞いたことあるけど、実際どうやるの？」
- 「他の人のコードを壊してしまったらどうしよう...」
- 「レビューで怒られたらどうしよう...」

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

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

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

### 前提環境
- Git 2.x以上
- GitHub アカウント
- お好みのエディタ

## プルリクエストとは？

### 個人開発との最大の違い

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

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

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

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

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

```mermaid
graph LR
    A[あなたの変更] --> B[プルリクエスト]
    B --> C{レビュー}
    C -->|承認| D[mainにマージ]
    C -->|修正依頼| E[コード修正]
    E --> B
```

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

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

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

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

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

```bash
# 最新の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: コードを変更してコミット

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

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

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

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

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

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

```bash
# こんなメッセージが出たら、表示されたコマンドをコピペ実行
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説明文のテンプレート：**
```markdown
## 概要
ユーザープロフィール表示機能を実装しました。

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

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

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

## 関連Issue
close #123
```

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

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

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

1. **必須対応（Request changes）**
   ```
   このままだとバグが発生します。修正をお願いします。
   ```

2. **提案（Comment）**
   ```
   こう書くともっと読みやすくなりますよ！
   ```

3. **質問**
   ```
   この処理の意図を教えてもらえますか？
   ```

### コメントへの対応方法

**修正が必要な場合：**

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

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

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

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

**GitHubでのコメント返信例：**

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

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

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

1. **感謝の気持ちを忘れない**
   - レビューは時間を使ってくれている
   - 「ありがとうございます」を言おう

2. **質問は積極的に**
   ```markdown
   この部分がよく理解できませんでした。
   もう少し詳しく教えていただけますか？
   ```

3. **議論は建設的に**
   - 意見が分かれたら、理由を説明
   - 必要ならSlackやミーティングで相談

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

### コンフリクトが発生した

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

```bash
# 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
```

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

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

```bash
# コミットメッセージだけ修正
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
```

### プッシュできない

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

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

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

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

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

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

**Conventional Commitsを使おう：**
- `feat:` 新機能
- `fix:` バグ修正
- `docs:` ドキュメント
- `style:` フォーマット修正
- `refactor:` リファクタリング
- `test:` テスト追加/修正
- `chore:` ビルドプロセスなど

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

https://qiita.com/tnb47/items/19b1a7b9996cc657225e

### ブランチ戦略

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

### PRのサイズ

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

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

## まとめ

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

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

## 参考リンク

- [GitHub公式ドキュメント - プルリクエストについて](https://docs.github.com/ja/pull-requests)
- [Conventional Commits](https://www.conventionalcommits.org/ja/)
- [Git-flow ワークフロー](https://www.atlassian.com/ja/git/tutorials/comparing-workflows/gitflow-workflow)
- [初心者向けGitコマンド一覧](https://qiita.com/kohga/items/dccf135b0af395f69144)