チーム開発

Pull Request（PR）とは？

Pull Request（プルリクエスト）は、 「このブランチの変更をメインブランチに取り込んでください」という依頼です。 GitHubの中核的な機能で、チーム開発のワークフローに欠かせません。

PRを通じて、コードレビュー、議論、CI（自動テスト）の確認を行い、 品質を保ちながらコードを統合します。

  Pull Request のワークフロー

  1. feature ブランチで開発
  2. リモートに push
  3. GitHub で Pull Request を作成
  4. レビュアーがコードを確認
  5. フィードバックを反映（追加コミット）
  6. 承認（Approve）
  7. main にマージ
  8. feature ブランチを削除

  ┌──────┐    push    ┌──────────┐    PR     ┌──────┐
  │ local │  ──────▶  │ feature  │  ──────▶  │ main │
  │ work  │           │ (remote) │  review   │      │
  └──────┘           └──────────┘  approve  └──────┘

Pull Requestの作成手順

# 1. feature ブランチで作業
$ git switch -c feature/user-profile
# ... ファイルを編集 ...
$ git add .
$ git commit -m "feat: ユーザープロフィール画面を追加"

# 2. リモートにpush
$ git push -u origin feature/user-profile

# 3. GitHubで「Compare & pull request」ボタンをクリック
#    または GitHub CLI を使用:
$ gh pr create --title "ユーザープロフィール画面を追加" \
               --body "## 変更内容
- プロフィール表示コンポーネントを作成
- APIからユーザー情報を取得する機能を追加

## スクリーンショット
（画像を貼る）"

良いPRの書き方

コードレビュー

PRに対して他のメンバーが変更内容を確認し、フィードバックを行います。 レビューはコードの品質向上だけでなく、知識の共有にも役立ちます。

レビューの3つのアクション

レビューのポイント

マージコンフリクトの解消（実践）

PRを作成した後にmainブランチが更新されると、コンフリクトが発生することがあります。 その場合の解消手順を見てみましょう。

# 1. main ブランチの最新を取得
$ git switch main
$ git pull origin main

# 2. feature ブランチに戻る
$ git switch feature/user-profile

# 3. main の変更を取り込む（ここでコンフリクト発生）
$ git merge main

Auto-merging src/components/Header.tsx
CONFLICT (content): Merge conflict in src/components/Header.tsx
Automatic merge failed; fix conflicts and then commit the result.

# 4. コンフリクトしたファイルを開いて解決
#    <<<<<<< ======= >>>>>>> のマーカーを削除して正しい内容にする

# コンフリクト箇所の例:
<<<<<<< HEAD (feature/user-profile)
<nav className="flex gap-4">
  <Link href="/profile">プロフィール</Link>
  <Link href="/settings">設定</Link>
</nav>
=======
<nav className="flex gap-6 items-center">
  <Link href="/dashboard">ダッシュボード</Link>
</nav>
>>>>>>> main

# 解決後（両方の変更を統合）:
<nav className="flex gap-6 items-center">
  <Link href="/dashboard">ダッシュボード</Link>
  <Link href="/profile">プロフィール</Link>
  <Link href="/settings">設定</Link>
</nav>

# 5. 解決したファイルをステージング
$ git add src/components/Header.tsx

# 6. マージコミットを作成
$ git commit -m "merge: main の変更を取り込み（コンフリクト解消）"

# 7. リモートにpush
$ git push origin feature/user-profile

Conventional Commits

Conventional Commits は、コミットメッセージに統一ルールを 設ける規約です。チーム開発で履歴を分かりやすくし、自動的なリリースノート生成にも活用されます。

<type>(<scope>): <description>

[optional body]

[optional footer]

主なtype（種類）

コミットメッセージの例

# 新機能
$ git commit -m "feat(auth): ログインフォームにパスワードリセット機能を追加"

# バグ修正
$ git commit -m "fix(header): モバイル表示でナビが崩れる問題を修正"

# ドキュメント
$ git commit -m "docs: READMEにセットアップ手順を追加"

# リファクタリング
$ git commit -m "refactor(api): ユーザー取得のAPIクライアントを整理"

# 破壊的変更（BREAKING CHANGE）
$ git commit -m "feat(api)!: レスポンス形式をv2に変更

BREAKING CHANGE: APIのレスポンス形式が変更されました。
クライアント側の修正が必要です。"

PRのマージ戦略

GitHubでPRをマージする際、3つの方法を選択できます。

main: A ── B ── E ── M (merge commit)
               \       /
feature:        C ── D

main: A ── B ── E ── S (squashed commit)

※ C, D が1つのコミット S にまとめられる

main: A ── B ── E ── C' ── D'

※ マージコミットなしの直線的な履歴

チーム開発のベストプラクティス