conventional-commits

Conventional Commits

すべてのコミットメッセージをConventional Commits仕様に従って記述します。これにより、変更履歴の自動生成、セマンティックバージョニング、より見やすいコミット履歴が可能になります。

フォーマットの構成

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

コミットタイプ

必須タイプ

• feat: - 新機能（セマンティックバージョニングのMINORに対応）
• fix: - バグ修正（セマンティックバージョニングのPATCHに対応）

よく使われる追加タイプ

• docs: - ドキュメントのみの変更
• style: - コードスタイルの変更（フォーマット、セミコロンの不足など）
• refactor: - バグ修正や新機能の追加を伴わないコードのリファクタリング
• perf: - パフォーマンスの改善
• test: - テストの追加または更新
• build: - ビルドシステムまたは外部依存関係の変更
• ci: - CI/CD設定の変更
• chore: - srcまたはtestファイルを変更しないその他の変更
• revert: - 以前のコミットの取り消し

スコープ

任意のスコープを指定すると、コードベース内の該当箇所について追加の文脈を示せます。

feat(parser): add ability to parse arrays
fix(auth): resolve token expiration issue
docs(readme): update installation instructions

説明

• タイプ／スコープの後に、コロンとスペースを挟んで続けます
• 命令形を使います（「added feature」や「adds feature」ではなく「add feature」）
• 先頭の文字は大文字にしません
• 末尾にピリオドを付けません
• 簡潔にまとめます（通常50～72文字）

本文

• 追加の文脈を示す、任意の長い説明です
• 説明の後に空行を1行入れて始めます
• 複数の段落で構成できます
• 変更の「方法」ではなく、「何を」「なぜ」変更するのかを説明します

破壊的変更

破壊的変更は、次の2つの方法で示せます。

1. タイプ／スコープに!を付ける

feat!: send an email to the customer when a product is shipped
feat(api)!: send an email to the customer when a product is shipped

2. BREAKING CHANGEフッターを使う

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

3. 両方の方法を使う

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

例

シンプルな機能追加

feat: add user authentication

スコープ付きの機能追加

feat(auth): add OAuth2 support

本文付きのバグ修正

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

破壊的変更

feat!: migrate to new API client

BREAKING CHANGE: The API client interface has changed. All methods now
return Promises instead of using callbacks.

ドキュメントの更新

docs: correct spelling of CHANGELOG

フッター付きの複数段落の本文

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

ガイドライン

1. 必ずタイプを使う - すべてのコミットは、タイプの後にコロンとスペースを付けて始めます
2. 命令形を使う - 「このコミットを適用すると、～する」の文を完成させるつもりで書きます
3. 具体的に書く - 説明から変更内容が明確に伝わるようにします
4. 焦点を絞る - 1つのコミットにつき、論理的な変更を1つにします
5. 必要に応じてスコープを使う - スコープを使うと、コードベース内で変更を分類しやすくなります
6. 破壊的変更を記録する - 破壊的変更は必ず明確に示します

セマンティックバージョニングとの対応

• fix: → PATCHバージョンの更新（1.0.0 → 1.0.1）
• feat: → MINORバージョンの更新（1.0.0 → 1.1.0）
• BREAKING CHANGE → MAJORバージョンの更新（1.0.0 → 2.0.0）

使用する場面

次の場合にこのフォーマットを使います。

• すべてのgitコミット
• コミットメッセージの生成
• プルリクエストのマージコミット
• ユーザーがコミットメッセージやgitコミットについて質問した場合

よくある間違いと回避方法

❌ Added new feature（過去形、大文字で始まる） ✅ feat: add new feature（命令形、小文字で始まる）

❌ fix: bug（曖昧すぎる） ✅ fix: resolve null pointer exception in user service

❌ feat: add feature（冗長） ✅ feat: add user profile page

❌ feat: Added OAuth support.（過去形、末尾にピリオドがある） ✅ feat: add OAuth support