Git
Pull Request運用
PRの作成ルール、レビュー体制、マージ戦略に関するガイドライン
PRの作成ルール
Pull Request（PR）は、コードの品質を保ち、チーム全体で知識を共有するための重要なプロセスです。
PRを作成するタイミング
- 機能開発やバグ修正が完了したとき
- レビューを受けたいとき
- 早期フィードバックが欲しい場合（Draft PR として作成）
Draft PR の活用
実装途中でもフィードバックが欲しい場合は、Draft PR（下書き状態のPR）を作成することで、早い段階で方向性を確認し、手戻りを防げます。
実装途中でもフィードバックが欲しい場合は、Draft PR（下書き状態のPR）を作成することで、早い段階で方向性を確認し、手戻りを防げます。
PRのタイトルとディスクリプション
タイトルの書き方
PRのタイトルは、変更内容を簡潔に表現します。
feat: ユーザー認証機能の追加
fix: ログインフォームのバリデーションエラー修正
API クライアントのエラーハンドリング改善
ユーザー一覧ページのパフォーマンス改善
update
fix bug
変更
PR
Conventional Commits の形式を使用することもできますが、必須ではありません。
プロジェクトに応じて、適切な命名規則を採用してください。
ディスクリプション（説明文）の書き方
PRの説明文は、プロジェクトに応じて適切な内容を記載してください。以下は参考例です：
## 変更内容
<!-- 何を変更したかを簡潔に説明 -->
## 変更理由
<!-- なぜこの変更が必要だったかを説明 -->
## 確認方法
<!-- レビュアーが動作確認できる手順 -->
## スクリーンショット（該当する場合）
<!-- UI変更がある場合はスクリーンショットを添付 -->
## チェックリスト
- [ ] ローカルで動作確認済み
- [ ] テストを追加または更新した
- [ ] ドキュメントを更新した（必要な場合）
- [ ] Breaking Changeがある場合は明記した
GitHub PR テンプレートについてプロジェクトで統一したテンプレートを使用する場合、リポジトリに
.github/pull_request_template.md を作成すると、PR作成時に自動的にテンプレートが適用されます。
テンプレートの内容はプロジェクトごとに調整してください。PRのサイズ
PRは小さく保つことを推奨します。
大きすぎるPRは避ける大規模なPRはレビューが困難になり、バグの見逃しや理解の誤りが発生しやすくなります。
大きな変更は複数のPRに分割することを検討してください。
マージ戦略
プロジェクトのデフォルト設定として、以下を推奨します：
- develop ブランチ: Squash and Merge
- main ブランチ: Merge Commit
ブランチ保護設定での制限ブランチ保護ルールで、許可するマージ方法を制限できます。
詳細はブランチ戦略を参照してください。
マージ後のブランチ削除
マージが完了したら、トピックブランチは削除します。
GitHubの設定で「マージ後に自動削除」を有効にすることを推奨します。