Pull Requests の魔法

1. マージから提案へ：なぜ Pull Request が必要なのか？

前回の講義では、ローカルのコンピューターでブランチをマージ（merge）する方法を学びました。1人で作業している場合はそれで問題ありません。しかし、プロジェクトにチーム全体が取り組んでいるとしたらどうでしょう？もし各自が自分の変更をそのままメインブランチ main にマージしてしまうと、すぐにカオスになります。誤ってバグを含むコードを追加したり、ビルドを壊したり、同僚の大事な作業を削除してしまうかもしれません。

これを避けるために、チーム開発では別のアプローチを取ります。変更をすぐにマージするのではなく、まずマージの提案を作成します。この提案はPull Request（略して PR）、またはプラットフォームによっては Merge Request と呼ばれます。

Pull Request は公式な依頼です。「私のブランチから変更を pull（取り込み）、それをメインブランチに merge（統合）してください。」という意味です。しかし、これは単なる依頼ではなく、main に取り込まれる前にコードを議論・検証・改善するための場でもあります。

2. Pull Request の標準ワークフロー

新しい機能を作成する際の典型的なワークフローを、ステップごとに見ていきましょう。

新しいタスク用のブランチを作成する前に、すべての完了したコミットを push し、メインブランチ main を Update Project で最新にしておきましょう.

そうしないと、main に残っていたローカルの「出し忘れ」コミットが新しい Pull Request に紛れ込み、同僚を混乱させてしまいます。

手順 1. 新しいタスク用のブランチを作成する。

これまでと同様に、新しい作業は専用のブランチを作ることから始めます。たとえば、コントリビューター向けのガイドラインファイルをプロジェクトに追加したいとします。ブランチ feature/add-contribution-guide を作成しましょう。

手順 2. 変更を加えてブランチを GitHub に送信（push）する。

新しいブランチで CONTRIBUTING.md ファイルを作成し（作成後に Add をクリック）、他の開発者へのメッセージを書きます。その後、わかりやすいメッセージで Commit and Push しましょう。例：docs: Add contribution guide。

これは重要なステップです！ Pull Request は、すでにリモートに存在するブランチを元に作成されます。したがって、PR を作成する前に、新しいブランチを GitHub に push しておく必要があります。

3. IntelliJ IDEA から Pull Request を作成する

ブランチが GitHub にあるので、Pull Request を作成できます。

手順 1. Pull Requests タブを開く。

IDE の左側に Pull Requests タブがあります。これを開き、+ アイコンをクリックして新しい PR を作成します。

手順 2. PR の情報を入力する。

IDE が Pull Request 作成用の便利なインターフェースを自動で開きます。あなたの役割は、それを適切に埋めることです。主な項目を見ていきましょう。

1. タイトル: IDE がここにブランチ名をそのまま入れることがありますが、これは良い実践ではありません。タイトルは短く、わかりやすく、変更の要旨を表すべきで、良いコミットメッセージと同じです。
2. 説明: ここでは、何を、そしてなぜ行ったのかを説明します。
3. レビュアー: コードを確認すべき同僚を1人以上選びます。学習用プロジェクトではこの手順は省略しますが、実務では必須です。
4. 担当者: 通常は自分を指定します。これは、あなたがこのタスクの作成者であり、レビュー後の修正について主な責任を負うことを意味します。

すべての項目を記入したら、Create Pull Request をクリックしましょう。

4. コードレビュー：チェックと議論

PR を作成すると、最も重要な段階であるコードレビュー（code review）が始まります。チームメンバーはあなたの PR を開き、すべての変更を確認してコメントを残すことができます。

コメントやディスカッションは、IDE の Pull Requests タブでそのまま確認できます。誰かがコメントを残せば通知が届きます。

修正を求められたらどうする？

簡単です。新しい PR を作る必要はありません。同じブランチで必要な変更を加え、新しいコミットを作成して push してください。GitHub 上の Pull Request は自動的に更新され、新しいコミットが追加されます。

5. 作業の完了：マージとブランチの削除

すべての指摘が解決され、チームがあなたの変更を承認したら、Pull Request をマージできます。通常はリードエンジニアが実施しますが、権限があれば自分で行うこともあります。

手順 1. Merge

マージは多くの場合、GitHub のサイト上で行います。PR の下に大きな緑のボタン Merge pull request が表示されます。これを押すと、あなたのコードはメインブランチ main の一部になります。

手順 2. ブランチの削除。

マージ後は、あなたの `feature` ブランチは不要になるため、リポジトリを散らかさないよう削除しましょう。GitHub は Delete branch ボタンを表示して、削除を提案してくれます。

IDE 上のローカルブランチも削除して、整頓を保つことを忘れないでください。これは同じブランチ管理メニューから実行できます。

6. コミットの3つのルール

良いコミットは、正しいメッセージだけでなく、正しい内容でもあります。変更履歴をクリーンで有益、そしてプロフェッショナルに保つために、次の3つのシンプルなルールに従いましょう。

ルール1: 規格に沿ったわかりやすいメッセージを書く

あなたのコミットは、チームと未来の自分へのメッセージです。「fix」や「update」ばかりの履歴はまったく役に立ちません。最も有名な規格は Conventional Commits で、次の構造を提案しています。

<type>: <short description>

タイプは、変更のカテゴリを表す短い単語です。

• feat:（feature）— 新機能。
• fix: — バグ修正。
• docs: — ドキュメントの変更。
• style: — ロジックに影響しないフォーマット調整。
• refactor: — 新機能の追加やバグ修正を伴わないコード変更。
• test: — テストの追加や修正。
• chore: — 依存関係の更新やビルド設定など、コード以外の雑務。

例:

• 悪い例: fixed bug
• 良い例: fix: Correct user login validation

• 悪い例: readme
• 良い例: docs: Update installation instructions

ルール2: 1コミット＝1つの論理的変更（原子性）

1つのコミットに、バグ修正・新機能の追加・既存コードのリファクタリングを詰め込まないでください。こうしたコミットはレビューが非常に難しく、もし何か問題が起きた場合でも安全に取り消すのはほぼ不可能です。

各コミットは、1つの具体的なタスクだけを解決すべきです。

• 悪い例: 「Update user page」という1つのコミットで、アバター用フィールドの追加、名前のバリデーションのバグ修正、ボタン色の変更を同時に行う。
• 良い例: 3つの別々のコミットに分ける：
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

小さく焦点の定まったコミットの方が、はるかに理解しやすく管理しやすいものです。

ルール3: コミットでプロジェクトを壊さない

メインブランチの各コミットは、プロジェクトを動作可能な状態に保つ必要があります。コミットする前に、少なくともコードがコンパイルできることを確認しましょう。しかし、システムの別の部分をうっかり壊していないとどう確信できるでしょうか？手動チェックだけに頼るのは危険です。

そこで自動化の出番です。本コースでは自動プロセスの設定までは行いませんが、実務でどのように機能するかは知っておくべきです。現代のチームは、GitHub Actions などの継続的インテグレーション（Continuous Integration, CI）を使用します。

どのように動くの？

コードとそのテストを書き、GitHub 上でワークフロー（workflow）を設定します。すると、Pull Request に push するたびに次のような「魔法」が起こります。

1. GitHub Actions がこのイベントを検知して、あなたのワークフローを起動します。
2. プロジェクトを自動で「ビルド」し、すべてのテストを実行します。
3. すべてのテストが成功すると、GitHub のコミットの横に 緑のチェック が表示されます。これは、あなたの変更が安全であることをチームに示す合図です。
4. テストが1つでも失敗すると、赤いバツが表示されます。そのような PR をメインブランチにマージすることは厳禁です。

            graph LR
            subgraph GitHub
            A[開発者] -- "push" --> B(リポジトリ)
            B -- "イベント: push" --> C{GitHub Actions}
            end

            subgraph ワークフロー
            C -- "開始" --> D[テストの実行]
            D --> E[成功]
            D --> F[失敗]
            end

            subgraph 通知
            F --> G((Email))
            G --> H[開発者]
            G --> I[チーム]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

通知を設定することもできます。テストが失敗した場合、GitHub Actions はあなたやチーム全体にメールを送ることができます。こうしたアプローチにより、テストは単なる形式ではなく開発の不可欠な一部となり、各メンバーが自分のコードの品質に責任を持つという文化が育まれます。