チーム開発フロー | Git レッスン7

🎯 このレッスンで学ぶこと

• Pull Request を作成して説明文を書けます。
• コードレビューの目的と基本的な見方がわかります。
• Fork → Clone → PR の流れ（OSS貢献の基本）を理解できます。
• チーム開発の基本ルールを知っています。

📖 復習 — コンフリクト解消のおさらい

• コンフリクト = 同じファイルの同じ行を2つのブランチで変更したとき発生
• マーカー（<<<, ===, >>>）を読んで手動で解消する
• git merge --abort でいつでもマージ前に戻れる

📋 1. Pull Request を作ろう

Pull Request（PR）とは、「このブランチの変更をマージしていいか確認してもらう」仕組みです。チーム開発では、直接 main にマージせず、必ず PR を通します。

PR の作成手順:

1. ブランチで作業してコミットする
2. ブランチを GitHub に push する

   git push origin feature/add-login

3. GitHub で「Compare & pull request」ボタンをクリック
4. タイトルと説明文を書く
5. 「Create pull request」をクリック

良い PR の書き方:

• タイトル: 何を変えたか一言で（例: 「ログインフォームを追加」）
• 説明文: 何を変えたか・なぜ変えたか・確認してほしいポイント

PR 説明文テンプレート例:

## 変更内容
- ログインフォームのHTMLとCSSを追加

## なぜこの変更が必要か
- ユーザーがアカウントにログインできるようにするため

## 確認してほしいポイント
- フォームのバリデーションが正しく動くか
- スマホ表示で崩れていないか

ターミナル出力例:

$ git push origin feature/add-login
Enumerating objects: 4, done.
...
To https://github.com/あなた/リポジトリ名.git
 * [new branch]      feature/add-login -> feature/add-login

👀 2. コードレビューの基本

コードレビューとは、チームメンバーが PR の変更内容を確認することです。

レビューの目的:

• 🐛 バグの早期発見
• 📚 チーム内の知識共有
• ✨ コードの品質向上

レビューで見るポイント:

• コードが意図通りに動くか
• わかりにくい部分はないか
• 改善できる点はないか

コメントの書き方:

• ✅ 具体的に: 「この変数名を userName にすると意味が伝わりやすいです」
• ❌ 曖昧に: 「ここ微妙」

🔄 3. レビュー後の修正とマージ

レビューで指摘を受けたら、以下の流れで対応します:

1. 指摘箇所を修正する（同じブランチで作業）
2. 修正をコミットして push する

   git add .
   git commit -m "レビュー指摘を修正"
   git push origin feature/add-login

   → 同じブランチに push すれば、PR に自動で反映されます

3. レビュアーが Approve（承認）する
4. Merge pull request ボタンでマージ
5. Delete branch ボタンでブランチを削除

🌍 4. OSS貢献の流れ（Fork & PR）

OSS（オープンソースソフトウェア）とは、誰でもコードを見たり改善したりできるプロジェクトです。あなたも貢献できます！

Fork & PR の流れ:

1. Fork — 他の人のリポジトリを自分のアカウントにコピー
2. Clone — 自分のフォークをローカルにダウンロード

   git clone https://github.com/自分/リポジトリ名.git

3. ブランチ作成 → 修正 → コミット → Push
4. Pull Request — 元のリポジトリに「この変更を取り込んでください」と依頼

📐 5. チーム開発のルール

• ① main ブランチは直接変更しない — 必ずブランチを作ってから作業する。main が壊れるとチーム全員の作業が止まるためです。
• ② 必ず PR 経由でマージする — 直接 git merge せず、GitHub の PR を使う。変更の記録が残り、後から「なぜこの変更をしたか」を追えます。
• ③ レビューを1人以上受けてからマージ — 自分だけで判断しない。別の視点でバグや改善点を見つけてもらえます。
• ④ マージ後はブランチを削除する — 不要なブランチを残さない。ブランチが増えすぎると「どれが作業中？」と混乱します。

💻 やってみよう！

自分のリポジトリで PR を作成してみましょう:

1. feature ブランチを作成して切り替え

   git switch -c feature/update-readme

2. README.md を編集してコミット

   echo "## 更新履歴" >> README.md
   git add README.md
   git commit -m "READMEに更新履歴セクションを追加"

3. GitHub に push

   git push origin feature/update-readme

   期待される出力:

   $ git push origin feature/update-readme
   Enumerating objects: 5, done.
   ...
   To https://github.com/あなた/リポジトリ名.git
    * [new branch]      feature/update-readme -> feature/update-readme

4. GitHub で「Compare & pull request」をクリック
5. 説明文を書いて PR を作成 → 自分で Merge して完了！

⚠️ よくあるミス

• PR の説明文を空にする — レビュアーが「何を確認すればいいか」わかりません。最低限「何を変えたか」「なぜ変えたか」を書きましょう。
• main に直接 push してしまう — git push origin main は禁止。必ずブランチを作ってから push し、PR 経由でマージしましょう。
• レビューコメントを無視してマージする — 指摘を確認せずにマージすると、バグが本番に入る原因になります。全てのコメントに対応してからマージしましょう。