docs(conventional-commits): add how to use

# Conventional Commits の簡単な使い方

::: note info
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`

:::note info
固有名詞（Node.js）や頭字語（CI、API）、具体的なコード内での表記（Rectクラス、Appコンポーネント）に関しては、そのまま大文字を使用することが一般的です。小文字にする必要はありません。
:::

:::note warn
ただし、<strong>\<type></strong>と<strong>\<scope></strong>（ここでは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の変更を伴うコミットメッセージがどのようになるかを示しています。

:::note warn
ただし、これらは一例であり、具体的なメッセージはプロジェクトの要件や変更の内容によります。
:::

## References

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

https://www.conventionalcommits.org/ja/v1.0.0/#%e4%bb%95%e6%a7%98