構成管理

23.1. GitHub Flowブランチ戦略

23.1.1. 基本原則

• main ブランチは常にデプロイ可能な状態を維持します。
• すべての作業は main から分岐したfeatureブランチで実行します。
• 作業完了後、Pull Requestを作成し、レビューを経て main にマージします。

23.1.2. ブランチネーミング

プレフィックス	用途	例
feature/	新機能開発	feature/user-registration
fix/	バグ修正	fix/login-redirect-error
hotfix/	プロダクション緊急修正	hotfix/payment-null-check
chore/	ビルド、設定、依存関係等の非機能作業	chore/update-spring-boot
docs/	ドキュメント作業	docs/api-specification
refactor/	リファクタリング	refactor/user-service-cleanup

23.1.3. ブランチネーミングルール

• 小文字とハイフン（-）のみ使用します。
• スラッシュ（/）はプレフィックスの区切りにのみ使用します。
• ブランチ名は作業内容を簡潔に説明します。
• イシュー番号がある場合は含めます：feature/123-user-registration

23.1.4. ワークフロー

---

23.2. コミットメッセージコンベンション

23.2.1. Conventional Commits

すべてのコミットメッセージはConventional Commits形式に従います。

<type>: <description>

[optional body]

23.2.2. タイプ一覧

タイプ	説明	例
feat	新機能	feat: ユーザープロフィール照会API追加
fix	バグ修正	fix: ログイン時のリダイレクトエラー修正
docs	ドキュメント変更	docs: API仕様書更新
style	コードフォーマット（動作変更なし）	style: import整理
refactor	リファクタリング（動作変更なし）	refactor: UserServiceメソッド抽出
test	テスト追加/修正	test: UserService単体テスト追加
chore	ビルド、設定変更	chore: Spring Boot 3.4.3アップデート
perf	パフォーマンス改善	perf: ユーザー一覧クエリ最適化
ci	CI設定変更	ci: CircleCIキャッシュ設定追加

23.2.3. コミットメッセージルール

• タイトルは50文字以内で記述します。
• タイトルは命令形で記述します。（「追加した」X → 「追加」O）
• タイトルの末尾にピリオドを付けません。
• 本文が必要な場合はタイトルと空行で区切ります。
• 日本語または英語のいずれかをプロジェクトごとに統一します。

---

23.3. Pull Requestルール

23.3.1. PR必須条件

項目	基準
レビュアー	最低1名以上の承認
CI	すべてのチェック通過（リント、ビルド、テスト）
コンフリクト	マージコンフリクト解消完了
ブランチ	main に対して最新状態

23.3.2. PRテンプレート

プロジェクトに .github/pull_request_template.md を含めます。

## 変更内容
<!-- このPRで変更した内容を簡潔に説明します -->

## 変更理由
<!-- なぜこの変更が必要なのかを説明します -->

## テスト
- [ ] 単体テスト追加/修正
- [ ] ローカルで動作確認

## 関連イシュー
<!-- 関連イシュー番号（例：#123） -->

23.3.3. マージ戦略

• Squash and Mergeをデフォルトとして使用します。
• マージ後、featureブランチは自動的に削除します。

---

23.4. .gitignore標準

23.4.1. 統合.gitignore例

# Java / Maven
target/
*.class
*.jar
*.war

# Spring Boot
*.log

# IDE
.idea/
*.iml
.vscode/*
!.vscode/settings.json
!.vscode/extensions.json

# Node.js
node_modules/
dist/

# 環境変数
.env.local
.env.*.local

# OS
.DS_Store
Thumbs.db

23.4.2. 原則

• ビルド成果物（target/、dist/）は追跡しません。
• IDE設定のうちチーム共有設定（.vscode/settings.json）のみ追跡します。
• ローカル環境変数（.env.local）は追跡しません。

---

23.5. バージョンタグ付け

23.5.1. Semantic Versioning

すべてのリリースはSemantic Versioning（SemVer）ルールに従います。

MAJOR.MINOR.PATCH

区分	変更タイミング	例
MAJOR	下位互換性が失われる変更	1.0.0 → 2.0.0
MINOR	下位互換性のある機能追加	1.0.0 → 1.1.0
PATCH	下位互換性のあるバグ修正	1.0.0 → 1.0.1

23.5.2. タグ形式

• Gitタグ形式：v{MAJOR}.{MINOR}.{PATCH}
• 例：v1.0.0、v1.2.3

git tag -a v1.0.0 -m "v1.0.0 リリース"
git push origin v1.0.0

23.5.3. リリースノート

すべてのリリースには変更内容を記述したリリースノートを作成します。コミットメッセージのタイプごとにグルーピングして作成します。