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

より詳しい規約についてはこちらを参照してください。