version-control-guidelines

# Version Control Guidelines

## 概要

このSkillは、Gitを使用したバージョン管理の運用ガイドラインを定義する。Conventional Commits形式のコミットメッセージ、適切なPRレビュープロセス、Semantic Versioningによるリリース管理など、品質を担保しつつ効率的な開発を実現することを目的とする。個人開発ではセルフレビュー可、チーム開発では最低1名のレビュー承認が必要となる。

## 責任範囲

このSkillは以下の範囲をカバーする:

- 個人開発とチーム開発の運用方針
- ブランチ戦略（個人開発・チーム開発別）
- コミットメッセージの記述ルール（Conventional Commits形式）
- プルリクエストのガイドライン
- マージ方針とコンフリクト解決
- タグとリリース管理（Semantic Versioning）

## 基本方針

### 共通ルール

以下のルールは個人開発・チーム開発に関わらず適用する:

- コミットメッセージ、PR、IssueにAI自動生成署名を記述しない
- メッセージは原則として英語で記述する
- チームの主要言語が英語以外の場合はその言語の使用を許可する
- プロジェクトにテンプレートがある場合はそちらを優先的に使用する

### 個人開発の場合

- シンプルなブランチ戦略を採用する
- コミットメッセージはConventional Commits形式で記述する
- セルフレビュー可
- 素早く実装して素早くリリースする
- ローカルでの実験的な作業を許容する

### チーム開発の場合

- Git Flowブランチ戦略を採用する
- コミットメッセージはConventional Commits形式で詳細に記述する
- 最低1名のレビュー承認が必要
- 品質とスピードのバランスを取る
- チーム全体でルールを統一する

## ブランチ戦略

### ブランチ戦略: 個人開発の場合

シンプルな2ブランチモデルを採用する。

**メインブランチ**:

- `main`: 本番環境にデプロイ可能な状態を保つ

**作業ブランチ**:

- `feat/機能名`: 新機能の開発
- `fix/修正内容`: バグ修正
- `exp/実験内容`: 実験的な実装（任意）

**運用フロー**:

1. `main`から作業ブランチを作成
2. 作業ブランチで実装
3. 動作確認後、`main`にマージ
4. 作業ブランチを削除

良い例:

```bash
# 新機能の開発
git checkout main
git pull
git checkout -b feat/user-auth
# 実装作業
git add .
git commit -m "ユーザー認証機能を実装"
git push origin feat/user-auth
# mainにマージ（PRは任意）
git checkout main
git merge feat/user-auth
git push origin main
git branch -d feat/user-auth
```

### ブランチ戦略: チーム開発の場合

Git Flow風のブランチモデルを採用する。

**永続ブランチ**:

- `main`: 本番環境にデプロイされている状態
- `develop`: 開発中の最新状態（次回リリース候補）

**一時ブランチ**:

- `feature/機能名`: 新機能の開発（developから分岐）
- `fix/修正内容`: バグ修正（developから分岐）
- `hotfix/緊急修正内容`: 本番環境の緊急修正（mainから分岐）
- `release/バージョン番号`: リリース準備（developから分岐）

**運用フロー**:

1. `develop`から作業ブランチを作成
2. 作業ブランチで実装
3. PRを作成してレビュー依頼
4. レビュー承認後、`develop`にマージ
5. リリース時に`develop`から`release`ブランチを作成
6. `release`ブランチで最終調整後、`main`と`develop`にマージ
7. `main`にタグを付ける

良い例:

```bash
# 新機能の開発
git checkout develop
git pull
git checkout -b feature/user-profile
# 実装作業
git add .
git commit -m "feat: ユーザープロフィール編集機能を実装"
git push origin fea