# バッチ設計書 28-husky commit-msg

## 概要

本ドキュメントは、Decap CMSプロジェクトにおけるGit commit-msgフックによるコミットメッセージのConventional Commits準拠検証バッチ `.husky/commit-msg` の設計を記述する。

### 本バッチの処理概要

本バッチは、Gitのcommit-msgフックとしてhuskyにより実行され、commitlintを使用してコミットメッセージがConventional Commits規約に準拠しているかを検証する。規約に違反したコミットメッセージが使用された場合、コミットを拒否して開発者にフィードバックを提供する。

**業務上の目的・背景**：Decap CMSプロジェクトでは、コミットメッセージの一貫性と品質を確保するためにConventional Commits規約を採用している。Lernaによるバージョン管理（独立バージョニング）では、コミットメッセージのプレフィックス（`feat:`, `fix:`, `chore:` 等）に基づいてセマンティックバージョニングの判定が行われる。そのため、規約に準拠しないコミットメッセージは、バージョン自動更新やCHANGELOG生成の精度に直接影響する。本バッチにより、不正なコミットメッセージがリポジトリに混入することを防止する。

**バッチの実行タイミング**：Gitの `git commit` コマンド実行時に自動的にフックとして実行される。開発者がコミットを作成するたびに実行される。

**主要な処理内容**：
1. huskyのシェル初期化スクリプト（`_/husky.sh`）の読み込み
2. commitlintの実行（`npx --no-install commitlint --edit $1`）
3. コミットメッセージファイル（`$1`）を入力として渡し、`@commitlint/config-conventional` ルールに基づく検証

**前後の処理との関連**：本フックは `git commit` 実行時にGitにより自動起動される。huskyは `npm install` 後の `prepare` スクリプト（`husky install`）により設定される。コミットメッセージが検証に合格した場合にのみコミットが成功する。Lernaのバージョン管理（`lerna.json` の `conventionalCommits: true`）と連動して、正しいプレフィックスに基づくバージョン更新が行われる。

**影響範囲**：全開発者のGitコミット操作。コミットメッセージのフォーマットに影響し、間接的にLernaのバージョニングとCHANGELOG生成にも影響する。

## バッチ種別

Git Hooks（コミットメッセージ検証）

## 実行スケジュール

| 項目 | 内容 |
|-----|------|
| 実行頻度 | `git commit` 実行時に毎回 |
| 実行時刻 | N/A（イベント駆動） |
| 実行曜日 | N/A |
| 実行日 | N/A |
| トリガー | Gitのcommit-msgフック（`git commit` 実行時に自動） |

## 実行条件

### 前提条件

| 条件 | 説明 |
|-----|------|
| huskyのインストール | `npm install` 後に `prepare` スクリプト（`husky install`）が実行済みであること |
| commitlintのインストール | `@commitlint/cli` がdevDependenciesとしてインストール済みであること |
| commitlint設定ファイル | `commitlint.config.js` がプロジェクトルートに存在すること |
| @commitlint/config-conventional | Conventional Commitsルールセットがインストール済みであること |

### 実行可否判定

huskyが正しくインストールされていれば、`git commit` 時に自動実行される。`--no-verify` オプションが指定された場合はフックがスキップされる。

## 入力仕様

### 入力パラメータ

| パラメータ名 | 型 | 必須 | デフォルト値 | 説明 |
|-------------|-----|-----|-------------|------|
| $1 | ファイルパス | Yes | なし | コミットメッセージが書かれた一時ファイルのパス（Gitが自動で渡す） |

### 入力データソース

| データソース | 形式 | 説明 |
|-------------|------|------|
| コミットメッセージファイル | テキスト | Gitが生成するコミットメッセージの一時ファイル |
| commitlint.config.js | JavaScript | commitlintのルール設定。`@commitlint/config-conventional` をextends |

## 出力仕様

### 出力データ

| 出力先 | 形式 | 説明 |
|-------|------|------|
| 標準出力/標準エラー | テキスト | 検証結果（エラー時のみエラーメッセージ） |
| プロセス終了コード | 数値 | 検証成功時0（コミット続行）、失敗時非0（コミット中止） |

### 出力ファイル仕様

本フックはファイル出力を行わない。

| 項目 | 内容 |
|-----|------|
| ファイル名 | N/A |
| 出力先 | N/A |
| 文字コード | N/A |
| 区切り文字 | N/A |

## 処理フロー

### 処理シーケンス

```
1. huskyシェル初期化
   └─ . "$(dirname "$0")/_/husky.sh" でhusky共通スクリプトを読み込み
2. commitlint実行
   ├─ npx --no-install commitlint --edit $1 を実行
   ├─ --no-install: npxのローカルパッケージのみ使用（ダウンロードしない）
   ├─ --edit: コミットメッセージファイルから内容を読み取り
   └─ $1: Gitが渡すコミットメッセージファイルのパス
3. 検証ルール適用
   ├─ commitlint.config.js の extends: ['@commitlint/config-conventional'] に基づく
   ├─ コミットメッセージのプレフィックス（type）の検証
   ├─ コミットメッセージの構造（type(scope): subject）の検証
   └─ ヘッダー長、本文、フッターの検証
4. 結果判定
   ├─ 検証成功: 終了コード0 → コミット成功
   └─ 検証失敗: 終了コード非0 → コミット中止、エラーメッセージ表示
```

### フローチャート

```mermaid
flowchart TD
    A["git commit 実行"] --> B["commit-msgフック起動"]
    B --> C["husky.sh 読み込み"]
    C --> D["commitlint --edit $1 実行"]
    D --> E{"Conventional Commits準拠?"}
    E -->|Yes| F["終了コード 0（コミット成功）"]
    E -->|No| G["終了コード 非0（コミット中止）"]
    G --> H["エラーメッセージ表示"]
```

## データベース操作仕様

### 操作別データベース影響一覧

本フックはデータベース操作を行わない。

| 処理 | 対象テーブル | 操作種別 | 概要 |
|-----|-------------|---------|------|
| N/A | N/A | N/A | データベース操作なし |

### テーブル別操作詳細

N/A

## エラー処理

### エラーケース一覧

| エラーコード | エラー種別 | 発生条件 | 対処方法 |
|------------|----------|---------|---------|
| 非0 | フォーマット違反 | コミットメッセージがConventional Commits規約に準拠しない | エラーメッセージを確認し、正しいフォーマット（例：`feat: add new feature`）でコミットする |
| N/A | commitlint不在 | commitlintがインストールされていない | `npm install` を実行してdevDependenciesをインストールする |
| N/A | 設定ファイル不在 | commitlint.config.jsが存在しない | 設定ファイルの存在を確認する |

### リトライ仕様

| 項目 | 内容 |
|-----|------|
| リトライ回数 | N/A（コミットメッセージを修正して再度 `git commit` を実行） |
| リトライ間隔 | N/A |
| リトライ対象エラー | N/A |

### 障害時対応

コミットメッセージの検証に失敗した場合、commitlintが出力するエラーメッセージに従ってコミットメッセージを修正する。緊急時は `git commit --no-verify` でフックをスキップ可能だが、推奨されない。

## トランザクション仕様

| 項目 | 内容 |
|-----|------|
| トランザクション範囲 | N/A（Git操作のフックのため該当なし） |
| コミットタイミング | N/A |
| ロールバック条件 | N/A |

## パフォーマンス要件

| 項目 | 内容 |
|-----|------|
| 想定処理件数 | 1コミットメッセージ/実行 |
| 目標処理時間 | 1秒以内 |
| メモリ使用量上限 | 最小限（commitlint実行分のみ） |

## 排他制御

排他制御は不要。各開発者のローカル環境で独立して実行される。

## ログ出力

| ログ種別 | 出力タイミング | 出力内容 |
|---------|--------------|---------|
| エラーログ | 検証失敗時 | commitlintのエラーメッセージ（違反ルール、期待されるフォーマット） |

## 監視・アラート

| 監視項目 | 閾値 | アラート先 |
|---------|-----|----------|
| N/A | N/A | ローカルGitフックのため監視対象外 |

## 備考

- `@commitlint/config-conventional` は以下のプレフィックス（type）を許可する：
  - `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`
- コミットメッセージの推奨フォーマット：`type(scope): subject`（例：`feat(widget): add color picker`）
- Lernaの `conventionalCommits: true` 設定と連動し、`feat:` は minor バージョンアップ、`fix:` は patch バージョンアップとして扱われる
- `BREAKING CHANGE` フッターがある場合は major バージョンアップとなる
- huskyはdevDependenciesとして `^7.0.0` がインストールされている
- `npx --no-install` により、commitlintが未インストールの場合はダウンロードせずにエラーとなる
- CI環境でのコミット（Lernaのパブリッシュコミット等）もこのフックの対象となるが、CI環境ではhuskyが無効化されている場合がある
