Top

Pull Request作成方針

本ドキュメントでは、Pull Request（PR）を作成する際のガイドラインをまとめます。円滑なレビューとコードの品質維持を目的としています。

PRは可能な限り小さく保つことを推奨します。

1つのPR = 1つの関心事（1つの機能追加・1つのバグ修正など）:
- 複数の修正を1つのPRに含めると、レビューの負荷が高まり、バグの見落としの原因になります。
目安としての行数:
- 200〜400行程度を超えるとレビューが困難になる傾向があります。大規模な変更になる場合は、PRを分割することを検討してください。
リファクタリングの扱い:
- 機能追加とリファクタリングは別のPRに分けるのが理想的です。

レビュアーが「何を」「なぜ」「どのように」変更したのかを即座に理解できるように記載します。

プレフィックスの活用: feat:, fix:, refactor:, docs: などのプレフィックスを付けることで、変更の種類を明示します。
簡潔な要約: 何の対応をしたかが一目でわかるようにします（例: feat: ログイン機能の実装）。
IDの紐付け: チケット番号や課題IDがある場合は含めます（例: [ISSUE-123] fix: バリデーションエラーの修正）。

以下の項目をテンプレートとして使用することを推奨します。

対応内容 / 目的:
- なぜこの変更が必要なのか、どのような背景があるのか。
主な変更点:
- 具体的にどこをどう変えたのか（大きな変更の場合は、技術的な設計判断も記載）。
影響範囲:
- この変更によって他に影響が出る箇所はあるか。
関連リンク（一次ソース）:
- 関連するチケット（Issue）やドキュメント、参考にした一次ソース（公式ドキュメント、技術仕様書など）のURLを記載します。
- 二次情報の記事（技術ブログなど）だけでなく、可能な限り信頼できるソースを提示することで、実装の正当性を裏付けます。

変更が正しく動作することを証明するために、テスト結果を記載します。

テスト内容:
- 実施したテストの種類（ユニットテスト、手動テストなど）と、確認したケース。
エビデンスの添付:
- UIの変更がある場合は、変更前後のスクリーンショットや動画を添付します。
- ログや実行結果のテキストを貼り付けることも有効です。
テスト自動化:
- テストコードが含まれている場合は、CIで通っていることを確認してください。

レビュアーが最小限のコストで、かつ自信を持って承認（Approve）できるように、読み手への「おもてなし」を意識します。

セルフレビューとセルフコメント:
- PRを作成する前に自分自身で差分を確認し、不要なコード（console.logなど）の削除や命名の最終確認を行います。
- 「なぜこうしたのか」という意図が伝わりにくい箇所には、あらかじめセルフコメントを付けて解説を添えます。 これにより、レビュアーが疑問に思う時間を削減できます。
要点の明示:
- 修正範囲が大きい場合は、特に重点的に見てほしいファイルや、ロジックの核となる部分を明記します。
Draft PR（下書き）の活用:
- 作業中の場合は Draft PR として作成し、フィードバックが欲しいタイミングで「Ready for review」に変更します。
図解や表の活用:
- ロジックが複雑な場合は、文章だけでなくシーケンス図や構成図を（Markdown形式などで）添えると非常に親切です。