VRUGD

Appearance

プルリクエストを作ってレビューしてもらう ​

このドキュメントは、開発作業が完了し、その変更内容をメインブランチに統合するためにプルリクエスト（Pull Request, PR）を作成し、チームメンバーにレビューを依頼する際の手順を説明するものです。

1. はじめに ​

プルリクエストは、自身が行った変更を他の開発者に通知し、コードレビューを受け、問題がなければマージ（統合）するためのGitHub上の機能です。丁寧なプルリクエストは、スムーズなレビューとプロジェクトの品質向上に繋がります。

2. 前提条件 ​

プルリクエストを作成する前に、以下の作業が完了していることを確認してください。

  • ローカルでの作業が完了し、関連する変更がコミットされていること。
  • 作業ブランチがリモートリポジトリ（GitHub）にプッシュされていること。
    bash
    git push origin <作業ブランチ名>
  • （可能であれば）ローカルでビルドやテストが成功していること。

3. プルリクエスト作成手順 ​

  1. GitHubリポジトリへアクセス:

    • ブラウザで対象のGitHubリポジトリページを開きます。

  2. プルリクエスト作成画面へ移動:

    • 方法1: プッシュ後の通知を利用する
      • 作業ブランチをプッシュすると、リポジトリのトップページに「Compare & pull request」という緑色のボタンが表示されることがあります。これをクリックします。
    • 方法2: 「Pull requests」タブから作成する
      • リポジトリのタブから「Pull requests」を選択し、「New pull request」ボタンをクリックします。

  3. ブランチの選択:

    • baseブランチ: マージ先のブランチを選択します。通常は main、master、または develop など、プロジェクトの主要な開発ブランチになります。
    • compareブランチ: マージ元のブランチ、つまりあなたが作業を行ったブランチを選択します。
    • ブランチを選択すると、変更差分（diff）が下に表示されるので、意図した変更が含まれているか確認してください。

  4. タイトルと説明の入力:

    • タイトル (Title):
      • プルリクエストの内容を簡潔かつ具体的に記述します。他の人がタイトルを見ただけで、どのような変更なのかを把握できるように心がけましょう。
      • 例:
        • feat: ユーザーログイン機能を追加
        • fix: 特定条件下での入力フォームの表示崩れを修正 (Issue #123)
        • docs: APIドキュメントの○○セクションを更新
      • プロジェクトによっては、接頭辞（feat:, fix:, docs:など）の規約がある場合があります。
    • 説明 (Description / Writeタブ):
      • 変更の目的、背景、具体的な変更内容、関連するIssue番号（例: Closes #123 や Fixes #123 と書くと、マージ時に自動でIssueをクローズできます）、レビュー担当者に特に見てほしい点、懸念事項、テスト方法などを記述します。
      • Markdown形式で記述できるため、箇条書きやコードブロック、スクリーンショットなどを活用して分かりやすく伝えましょう。
      • 含めるべき内容の例:
        • このプルリクエストは何をするものか？ (What)
        • なぜこの変更が必要なのか？ (Why) (関連するIssue、改善される点など)
        • どのように実装したのか？ (How) (技術的な選択、特に工夫した点など)
        • 確認してほしいこと・懸念点
        • 動作確認方法・テスト内容
        • 関連する資料やスクリーンショット (もしあれば)
      • テンプレートが用意されている場合は、それに沿って記述してください。

  5. レビュアーの指定 (Reviewers):

    • 画面右側のサイドバーにある「Reviewers」セクションで、レビューを依頼したいチームメンバーを選択します。
    • レビュアーを指定すると、そのメンバーに通知が送られます。誰にレビューを依頼すべきか不明な場合は、チームリーダーやメンターに相談しましょう。

  6. ラベルやマイルストーンの設定 (任意):

    • 必要に応じて、「Labels」（例: bug, enhancement, documentation など）や「Milestone」を設定し、プルリクエストを分類・管理しやすくします。

  7. プルリクエストの作成実行:

    • すべての情報を入力・確認したら、「Create pull request」ボタンをクリックします。

4. レビュー依頼のポイントとマナー ​

  • レビュアーへの通知: GitHub上でレビュアーを指定すれば自動で通知が行きますが、チームのコミュニケーションルールによっては、チャットツールなどで別途「プルリクエストを作成したのでレビューお願いします」と一言連絡を入れるとより丁寧です。その際、プルリクエストのURLも共有しましょう。
  • レビューしやすいプルリクエストを心がける:
    • 変更範囲を適切に保つ: 一つのプルリクエストにあれもこれもと変更を詰め込みすぎず、関連する変更に絞りましょう。巨大なプルリクエストはレビューの負担が大きくなります。
    • セルフレビューを行う: プルリクエストを作成する前に、自分でコードを見直し、誤字脱字、不要なコメント、デバッグコードの残存などがないか確認しましょう。GitHubの差分表示画面でセルフチェックするのも有効です。
    • 動作確認をしっかり行う: 変更によって既存機能が壊れていないか、意図した通りに動作するかを確認してからレビューを依頼しましょう。
  • レビュアーへの敬意を払う: レビュアーは貴重な時間を使ってコードを確認してくれます。感謝の気持ちを持ち、指摘は真摯に受け止めましょう。

プールリクエストのコメントについて

プルリクエストに厳しいコメントがつくと、ちょっぴり心が折れそうになることもあるかもしれません。
たくさんのコメントに圧倒されて、「自分がダメなのかな…」と感じてしまうのも無理はありません。
それは、誰もが一度は通る道なんです。

でも、どうか思い出してください。
レビューコメントは、あなた個人に向けられたものではなく、
あくまでソースコードに対してつけられているものです。

レビュー担当者は、決してあなたを責めているわけではありません。
むしろ、あなたの成長を心から願って、より良いコードを書けるようにサポートしたいと思っています。
（もしそうでなければ、直接コードを修正する方がずっと手っ取り早いですからね！）

だから、どうかめげずに、一緒にこの壁を乗り越えていきましょう！
レビュアーはいつもあなたの味方です。

5. プルリクエスト作成後の流れ ​

  1. レビュー待ち: レビュアーからのフィードバックを待ちます。
  2. コメントへの対応:
    • レビュアーからコメントや質問、修正依頼があった場合は、内容を確認し、適切に対応します。
    • 修正が必要な場合は、ローカルの作業ブランチでコードを修正し、再度コミットしてプッシュします。プルリクエストは自動的に更新されます。
    • コメントに対して返信する場合は、GitHub上でスレッドに返信しましょう。
  3. ディスカッション: 必要に応じて、レビュアーと設計や実装についてディスカッションを行います。
  4. 承認 (Approve): レビューの結果、問題がなければレビュアーがプルリクエストを承認します。
  5. マージ (Merge):
    • 通常、リポジトリの管理者や権限を持つメンバーが、承認されたプルリクエストをbaseブランチ（例: main）にマージします。
    • マージ後、作業ブランチは不要になるため、削除されるのが一般的です（GitHub上でマージ時に自動削除するオプションもあります）。

この手順に従い、効果的なプルリクエストを作成し、スムーズなレビュープロセスを実現しましょう。不明な点があれば、チームメンバーやメンターに気軽に相談してください。