05.ブランチ規定

このドキュメントでは、Gitのブランチ戦略と、各ブランチの命名規則および運用ルールについて定めます。一貫したブランチ戦略は、複数人での並行開発を可能にし、変更履歴の追跡と安全なリリースを両立させます。

Success

"このプロジェクトのブランチ戦略の核心" このプロジェクトでは、開発者が日常的に作業する開発の最前線を main ブランチとします。一方で、ユーザーに提供される安定版は release ブランチで管理します。 main ブランチは必ずしもリリース可能ではないため、ご注意ください。

1. ブランチ戦略の全体像

本プロジェクトでは、開発の速度とリリースの安全性を両立させるため、以下の主要なブランチを永続的に運用します。

main: 次期リリースに向けた最新の開発ブランチ。
release: ユーザーに提供される、テスト済みの安定版ブランチ。

この2つの主要ブランチに加え、作業内容に応じてfeature/*やhotfix/*といった一時的なブランチを作成します。

2. 主要ブランチの役割

2.1. `main` ブランチ (開発ブランチ)

役割: 全ての開発の主軸となるブランチです。次期リリースに向けた新機能や修正は、このブランチに集約されます。
運用ルール:
- 開発者は、後述するfeatureブランチをmainブランチから作成します。
- featureブランチでの作業完了後、Pull Requestを通じてmainブランチにマージします。
- このブランチに直接コミットすることは禁止します。

2.2. `release` ブランチ (安定版ブランチ)

役割: 常にリリース可能な状態、または実際にリリースされた状態を保持する安定版ブランチです。
運用ルール:
- このブランチに直接コミットすることは禁止します。
- このブランチへの変更は、後述するhotfixブランチのマージ、または計画的なリリース作業によってのみ行われます。

3. 作業ブランチの種類とワークフロー

3.1. 計画的な開発 (`feature/*`)

目的: 新機能の追加、リファクタリング、ドキュメント修正など、Hotfix以外の全ての計画的な作業に使用します。
命名規則: feature/[Issue番号]-[概要] (例: feature/12-user-profile-page)

!!! info "featureブランチの役割について" feature/* ブランチは、新機能の開発だけでなく、リファクタリング、ドキュメントの修正、テストの追加、ビルド設定の変更など、Hotfix以外の全ての計画的な作業に使用します。

ワークフロー:
1. mainブランチから、作業内容に応じた名前でfeatureブランチを作成します。
2. ローカル環境で開発を行い、コミットします。
3. 作業が完了したら、mainブランチへのPull Requestを作成します。
4. コードレビューとCIチェックを経て、承認されたらmainブランチにマージします。

3.2. 緊急のバグ修正 (`hotfix/*`)

目的: releaseブランチで発見された、緊急に対応が必要なバグを修正するために使用します。
命名規則: hotfix/[Issue番号]-[修正の概要] (例: hotfix/45-fix-login-crash)
ワークフロー:
1. 安定版であるreleaseブランチから、hotfixブランチを作成します。
2. 修正作業を行い、コミットします。
3. 作業が完了したら、2つのPull Requestをそれぞれ作成します。
  - PR #1 (本番リリース用): hotfix/* → release
  - PR #2 (開発への反映用): hotfix/* → main
4. PR #1を最優先でレビュー＆マージし、安定版を更新します。これにより、ユーザーへの迅速なパッチ提供が可能になります。
5. その後、PR #2をレビュー＆マージし、開発ブランチにも修正を反映させます。これにより、将来のリリースで同じバグが再発することを防ぎます。

Hotfixでは必ず2つのPRを作成

Hotfixの修正をreleaseブランチとmainブランチの両方に反映させることは、バグの再発を防ぐために極めて重要です。このプロセスを省略してはいけません。

4. リリース作業について

mainブランチで開発された機能群を、releaseブランチに反映させ、新しいバージョンとしてリリースする作業（例: v1.1.0のリリース）については、05.リリース規定で別途定めます。

5. コミットメッセージの指針

コミットメッセージは、変更内容が後から追いやすいように、Conventional Commitsの規約に準拠します。この規約に従うことで、コミット履歴が人間にとって読みやすくなるだけでなく、変更履歴（CHANGELOG）の自動生成や、セマンティックなバージョン管理が容易になります。

5.1. コミットメッセージの構造

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Header (必須): <type>(<scope>): <subject> の形式。
Body (任意): 変更の動機や詳細な背景。
Footer (任意): BREAKING CHANGE: や Closes #123 などの情報。

5.2. `<type>` の種類 (必須)

タイプ	説明	主な使途
`feat`	新機能の追加	機能開発
`fix`	バグ修正	バグ修正、Hotfix
`docs`	ドキュメントのみの変更	ドキュメント作成・修正
`style`	コードの挙動に影響しない、見た目に関する変更	リンター/フォーマッター修正
`refactor`	コードの内部的な改善（リファクタリング）	内部品質の向上
`perf`	パフォーマンスを向上させるためのコード変更	性能改善
`test`	不足しているテストの追加や、既存テストの修正	テストコード修正
`build`	ビルドシステムや外部の依存関係への変更	CI/CD、ビルド関連
`ci`	CI設定ファイルやスクリプトへの変更	GitHub Actions修正など
`chore`	上記以外の雑務	ライブラリ更新など

5.3. `<subject>` の書き方 (必須)

日本語でのsubject書き方

簡潔で明確な表現: 何をしたかが一目で分かるよう、50文字以内で簡潔に記述する。
動詞で始める: 「追加」「修正」「削除」「更新」などの動詞から始める。
敬語は使わない: 「します」「いたします」などの敬語表現は避け、簡潔な表現にする。
句読点は使わない: 文末に「。」や「、」を付けない。

英語でのsubject書き方

動詞の原形から始める（命令形）。
文頭を大文字にしない。
文末にピリオドを付けない。
50文字以内を目指す。

良い例・悪い例

日本語の場合:

良い例: feat: ユーザーログアウト機能を追加
悪い例: feat: ユーザーログアウト機能を追加しました。

英語の場合:

良い例: feat: add user logout functionality
悪い例: fix: Fixed a bug.

5.4. `<footer>` の書き方 (任意)

破壊的変更: BREAKING CHANGE: から始まるフッターを必ず記述します。
Issueのクローズ: Closes #[Issue番号] や Fixes #[Issue番号] を記述します。

5.5. コミットメッセージの例

feat(auth): ユーザーログアウト機能を追加

ユーザーがアカウントからログアウトできる機能を実装。
セキュリティとユーザーエクスペリエンスの向上を図る。

BREAKING CHANGE: ログアウトエンドポイントで有効なセッショントークンが必須になりました。

fix(profile): ユーザープロフィール読み込みエラーを修正

プロフィールページでデータが正しく表示されない問題を解決。

Closes #42

docs: セットアップガイドにPrettier設定手順を追加

新規開発者向けにコードフォーマッターの設定方法を詳しく説明。

feat(ui): ナビゲーションメニューにダークモード切り替えを追加

ユーザーの視認性向上のため、ライト/ダークテーマの切り替え機能を実装。

test: ユーザー認証フローの単体テストを追加

ログイン、ログアウト、パスワードリセット機能のテストカバレッジを改善。

refactor(api): データベース接続処理を共通化

重複していたDB接続ロジックを統一し、保守性を向上。

fix(mobile): スマートフォンでのレスポンシブ表示を修正

画面幅768px以下でのレイアウト崩れを解消。

Fixes #128

build: package.jsonにPrettierとlinting関連依存関係を追加

開発環境の統一とコード品質向上のため、フォーマッターとリンターを導入。

ci: GitHub ActionsにPrettierチェックを追加

プルリクエスト時に自動的にコードフォーマットをチェックする仕組みを構築。

chore: 依存関係をセキュリティパッチ適用版に更新

脆弱性対応のため、npm auditで検出された問題のあるパッケージを更新。

05.ブランチ規定

1. ブランチ戦略の全体像

2. 主要ブランチの役割

2.1. main ブランチ (開発ブランチ)

2.2. release ブランチ (安定版ブランチ)

3. 作業ブランチの種類とワークフロー

3.1. 計画的な開発 (feature/*)

3.2. 緊急のバグ修正 (hotfix/*)

4. リリース作業について

5. コミットメッセージの指針

5.1. コミットメッセージの構造

5.2. <type> の種類 (必須)

5.3. <subject> の書き方 (必須)

日本語でのsubject書き方

英語でのsubject書き方

良い例・悪い例

5.4. <footer> の書き方 (任意)

5.5. コミットメッセージの例

2.1. `main` ブランチ (開発ブランチ)

2.2. `release` ブランチ (安定版ブランチ)

3.1. 計画的な開発 (`feature/*`)

3.2. 緊急のバグ修正 (`hotfix/*`)

5.2. `<type>` の種類 (必須)

5.3. `<subject>` の書き方 (必須)

5.4. `<footer>` の書き方 (任意)