GLANZ. CREATIVE WORKS
Git

Pull Request運用

PRの作成ルール、レビュー体制、マージ戦略に関するガイドライン

PRの作成ルール

Pull Request（PR）は、コードの品質を保ち、チーム全体で知識を共有するための重要なプロセスです。

PRを作成するタイミング

  • 機能開発やバグ修正が完了したとき
  • レビューを受けたいとき
  • 早期フィードバックが欲しい場合（Draft PR として作成）
Draft PR の活用
実装途中でもフィードバックが欲しい場合は、Draft PR（下書き状態のPR）を作成することで、早い段階で方向性を確認し、手戻りを防げます。

PRのタイトルとディスクリプション

タイトルの書き方

PRのタイトルは、変更内容を簡潔に表現します。

feat: ユーザー認証機能の追加
fix: ログインフォームのバリデーションエラー修正
API クライアントのエラーハンドリング改善
ユーザー一覧ページのパフォーマンス改善
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の設定で「マージ後に自動削除」を有効にすることを推奨します。

コミットメッセージとタグ

Conventional Commitsに準拠したコミットメッセージの書き方とタグ運用

リポジトリ運用

リポジトリの所有者、責任範囲、命名規則、可視性設定に関するガイドライン

Copyright © 2026