Conventional Commits の簡単な使い方
Conventional Commitsを使用すると、コミットログが一貫性を持ち、自動化ツール（例えば、セマンティックバージョニングやチェンジログ生成）が容易に利用できます。
全体の形式について
記述の形式
Conventional Commitsはコミットメッセージの構造を標準化するための規約で、以下の形式に従います：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
各部分の解説
各部分の説明は以下の通りです：
-
<type>: コミットの種類を示します。一般的なタイプにはfeat（新機能）、fix（バグ修正）、docs（ドキュメンテーションの変更）、style（コードのスタイルのみの変更）、refactor（バグ修正や機能追加を伴わないコードの改善）、perf（パフォーマンスの改善）、test（テストの追加や修正）、chore（ビルドプロセスや補助ツール、ライブラリの更新などの変更）などがあります。 -
<scope>: コミットが影響を与える範囲を示します。これはオプションで、具体的なモジュール名やファイル名などを指定します。 -
<subject>: コミットの短い説明を提供します。50文字以内で書くことが推奨されています。 -
<body>: 必要に応じてコミットの詳細な説明を提供します。これはオプションです。 -
<footer>: 他の情報（例えば、関連するIssue番号など）を記載します。これもオプションです。
<type>(<scope>): <subject> について
e.g.
以下にいくつかの例を示します：
- 新機能の追加：
feat(parser): add ability to parse arrays - バグ修正：
fix(login): fix login issue - ドキュメンテーションの変更：
docs(readme): update install instructions - リファクタリング：
refactor(utils): simplify validation logic - テストの追加：
test(login): add login test case - ビルドプロセスの変更：
chore(build): update build script
さらに例を示します：
- パフォーマンス改善：
perf(database): improve database connection pooling - コードスタイルの変更：
style(login): fix indentation - リファクタリング（機能追加やバグ修正を伴わないコードの改善）：
refactor(utils): separate validation into its own function - テストの追加：
test(api): add tests for new API endpoint - ビルドプロセスや補助ツールの変更：
chore(ci): add Node.js 14 to CI matrix
固有名詞（Node.js）や頭字語（CI、API）、具体的なコード内での表記（Rectクラス、Appコンポーネント）に関しては、そのまま大文字を使用することが一般的です。小文字にする必要はありません。
ただし、<type>と<scope>（ここではchoreとci）はいかなる場合も小文字であるべきです。これはConventional Commitsの規約によるものです。
- ドキュメンテーションの変更：
docs(api): update API documentation for new endpoint - バグ修正とIssueのクローズ：
fix(login): fix login redirect bug (closes #1234)
破壊的変更（後方互換性を破る変更）
Conventional Commitsの規約では、破壊的変更（breaking change） を示すために!を使用します。これはコミットメッセージの<type>と<scope>の後に配置されます。例えば：
feat(user)!: remove old user verification method
このメッセージは、userスコープで既存のユーザー認証方法を削除したという新機能を示しています。
また、コミットメッセージの<body>または<footer>部分で、具体的な破壊的変更の詳細をBREAKING CHANGE:というフレーズを使って説明することが推奨されています。例えば：
feat(user)!: remove old user verification method
BREAKING CHANGE: The old user verification method is removed. All users must now use the new verification method.
以下に、破壊的変更を伴うコミットメッセージの例をいくつか示します：
- 既存のユーザー認証方法を削除したという新機能を示す：
feat(user)!: remove old user verification method - ユーザー認証方法の削除：
feat(auth)!: remove old authentication method - APIエンドポイントの変更：
feat(api)!: change /old-endpoint to /new-endpoint - データベーススキーマの変更：
feat(database)!: remove old_column from users table - 必須の環境変数の追加：
feat(config)!: add new required ENV_VAR - 既存の関数の引数の変更：
feat(utils)!: change arguments of calculate function
その他
CSS（蛇足かもしれません…）
CSSの変更を伴うコミットメッセージは、変更の内容によりますが、一般的にはstyleタイプを使用します。以下にいくつかの例を示します：
- CSSスタイルの変更：
style(layout): change padding of main container - 新しいCSSクラスの追加：
style(buttons): add new .button-primary class - CSSのリファクタリング：
refactor(styles): consolidate duplicate CSS rules - CSSのバグ修正：
fix(styles): fix overflow issue in header - CSSの破壊的変更：
style(colors)!: change primary color from blue to green
これらの例は、CSSの変更を伴うコミットメッセージがどのようになるかを示しています。
ただし、これらは一例であり、具体的なメッセージはプロジェクトの要件や変更の内容によります。
References
より詳しい規約についてはこちらを参照してください。