Pull Requestsのマジック

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

前の講義ではローカル環境でブランチをマージ（merge）する方法を学びました。これは一人で作業しているときにはうまく機能します。しかし、プロジェクトにチームで取り組んでいるとどうでしょう？全員が自分の変更を直接メインブランチmainにマージしてしまうと、すぐにカオスになります：誰かが誤ってバグのあるコードを入れたり、ビルドを壊したり、同僚の重要な作業を消してしまうかもしれません。

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

Pull Requestは公式なお願いです：「どうか私のブランチから変更をpullしてmainにmergeしてください」。でもこれは単なるお願いではなく、mainに入る前に議論、確認、改善を行うためのプラットフォームでもあります。

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

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

新しいタスク用のブランチを作る前に、必ず自分の完了したコミットをすべてpushして、mainブランチをUpdate Projectで最新にしておいてください。

そうしないと、ローカルの「忘れていた」コミットが新しい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. レビューア：あなたのコードをチェックしてくれる同僚を一人か複数選びます。学習用プロジェクトではこのステップを省略してもいいですが、実務では必須です。
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. コミットの三つのルール

良いコミットは、正しいメッセージだけでなく正しい内容も重要です。変更履歴をきれいで役に立ち、プロフェッショナルに保つために、次の三つの簡単なルールを守ってください。

ルール1：標準に沿ったわかりやすいメッセージを書く

コミットはチームや未来の自分へのメッセージです。"fix"や"update"だけの履歴は全く役に立ちません。最も人気のある標準はConventional Commitsです。提案されている構造は次のとおりです：

<type>: <短い説明>

typeは変更のカテゴリを示す短い語です：

• feat: (feature) — 新しい機能のため。
• fix: — バグ修正のため。
• docs: — ドキュメントの変更のため。
• style: — 形式の修正（コードのロジックに影響しない）。
• refactor: — 新機能追加やバグ修正ではないコードの変更。
• test: — テストの追加や修正のため。
• chore: — 依存関係の更新やビルド設定などのルーチン作業のため。

例：

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

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

ルール2：一つのコミットは一つの論理的変更にする（アトミック性）

一つのコミットにバグ修正、新機能追加、古いコードのリファクタリングを詰め込もうとしないでください。そんなコミットはレビューが非常に難しく、何か問題があったときに取り消すのもほぼ不可能です。

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

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

小さく焦点の定まったコミットは理解と管理がずっと簡単です。

ルール3：コミットはプロジェクトを壊してはいけない

メインブランチの各コミットはプロジェクトを動く状態に保つべきです。コミットを作成する前に少なくともコードがコンパイルすることを確認してください。しかし、別の部分を壊していないかどうかをどう保証しますか？手動チェックだけに頼るのはリスキーです。

ここで役に立つのが自動化です。このコースでは自動化プロセスの設定までは扱いませんが、実際のプロジェクトでどのように動くかは知っておくべきです。現代のチームはContinuous Integration（CI）システム、例えばGitHub Actionsを使います。

仕組みは？

あなたはコードとそのテストを書きます。次にGitHub上でワークフロー（workflow）を設定します。すると、あなたがPull Requestにpushするたびにマジックが起きます：

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

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

            subgraph Workflow
            C -- "実行" --> D[テスト実行]
            D --> E[成功]
            D --> F[失敗]
            end

            subgraph Notifications
            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があなたやチーム全体にメールを送るようにできます。こうしたやり方は、テストが単なる形式ではなく開発の不可欠な一部である文化を作り出し、各自が自分のコードの品質に責任を持つことを促します。