06.プルリクエスト規定

このドキュメントは、プルリクエスト（Pull Request, PR）の作成と運用に関するルールを定めます。 PRは、変更をmainブランチに統合するための、唯一の公式な方法です。

1. PRの目的

品質の担保: 変更内容をマージする前に、他の開発者（またはAI）によるレビューと、GitHub Actionsによる自動チェック（CI）を実施します。
知識の共有: どのような変更が、なぜ行われたのかをチーム全体で共有し、属人化を防ぎます。
議論の場: 変更内容に対するフィードバックや、より良い実装方法についての議論を行います。

2. PR作成のルール

2.1. タイトルの書き方

Conventional Commitsの採用:
- PRのタイトルには、変更内容を示すプレフィックスを付けることを強く推奨します。これにより、変更の意図が一目で分かります。
- プレフィックスは、対応するブランチのプレフィックスや、IssueのType:ラベルと一致させます。
- 例:
  - feat: ログイン機能のAPIエンドポイントを追加
  - fix: ユーザー情報更新時のバリデーションエラーを修正
  - docs: ブランチ規定にHotfixフローを追記
具体性:
- タイトルだけで、PRの目的が理解できるように、具体的かつ簡潔に記述します。

2.2. 本文 (Description) の書き方

関連Issueとの連携:
- 本文のどこかに、Closes #[Issue番号] または Fixes #[Issue番号] を必ず記述します。
- これにより、このPRがマージされた際に、関連するIssueが自動的にクローズされ、作業の完了が明確になります。
変更点の要約:
- 何を (What): どのような変更を行ったのかを簡潔に記述します。
- なぜ (Why): なぜこの変更が必要だったのか、背景や目的を記述します。
レビュー依頼事項 (任意):
- 特に重点的に見てほしい箇所や、実装に悩んだ点、レビューアに判断を仰ぎたいことなどがあれば、具体的に記述します。
UIの変更を伴う場合:
- 画面の見た目が変わる場合は、変更前後のスクリーンショットやGIF動画を貼り付けることを強く推奨します。これにより、レビューアの確認コストが大幅に削減されます。

2.3. ドラフトプルリクエストの活用

まだ作業途中で、レビューを依頼する段階ではないが、CIを走らせたり、他の人から途中経過のフィードバックが欲しかったりする場合には、ドラフトプルリクエスト (Draft Pull Request) を作成します。
ドラフト状態のPRは、レビュー担当者に正式な通知が飛ばず、誤ってマージされることも防げます。作業が完了したら、「Ready for review」ボタンを押して通常のPRに切り替えます。

3. レビューとマージのプロセス

レビュー担当者の割り当て:
- PRを作成したら、適切なレビュー担当者（Assignees/Reviewers）を1名以上設定します。
セルフレビュー:
- 担当者を割り当てる前に、まずはPRの作成者自身が「Files changed」タブで、自分の変更内容に間違いがないか、デバッグコードなどが残っていないかを必ず確認します。
自動チェック (CI) の確認:
- PR上で実行されるGitHub Actionsのステータスチェックが、全て成功（✅）していることを確認します。
承認 (Approve):
- レビューアは、変更内容に問題がなければ「Approve」します。修正が必要な場合は、具体的なコメントを残します。
マージ:
- 全てのCIが成功し、規定数の承認が得られたら、PRの作成者がmainブランチにマージします。
- マージ方法: 原則として Squash and merge を推奨します。
- Squash and mergeを推奨する理由:
  - クリーンな履歴: ブランチ内の複数の作業コミット（「作業中」「修正」「テスト追加」など）を1つの意味のあるコミットにまとめることで、mainブランチの履歴がPR単位で整理され、見やすくなります。
  - 変更の追跡: 機能やバグ修正を1つのコミットとして記録するため、後から特定の変更を探したり、影響範囲を把握したりしやすくなります。
  - リバート（取り消し）の簡素化: 問題のある変更を取り消す際、1つのコミットをリバートするだけで、PR全体の変更を安全に元に戻すことができます。

関連ドキュメント: - 01.開発フロー概要 - 05.ブランチ規定