無効または認識されないコミットタイプ
許可リストにないコミットタイプを使用するとどうなるか。標準的なConventional Commitsタイプとカスタムタイプの追加方法を学びます。
Common Mistakes
詳細な説明
認識されるタイプ
Conventional Commits仕様では、feat(新機能)とfix(バグ修正)の2つのタイプのみが必須として定義されています。しかし、コミュニティはAngularの規約に基づいてより広範な標準タイプセットを確立しました:
| タイプ | 目的 | バージョンバンプ |
|---|---|---|
feat |
新機能 | マイナー |
fix |
バグ修正 | パッチ |
docs |
ドキュメントのみ | なし |
style |
フォーマット、空白 | なし |
refactor |
コード再構築 | なし |
perf |
パフォーマンス改善 | パッチ |
test |
テストの追加/修正 | なし |
build |
ビルドシステムの変更 | なし |
ci |
CI設定 | なし |
chore |
メンテナンスタスク | なし |
revert |
コミットの取り消し | 依存 |
無効な例
update: change user avatar size
updateは認識されたタイプではありません。変更に応じて、feat、fix、style、またはrefactorにすべきです。
bugfix: resolve login timeout
bugfixは標準ではありません — 代わりにfixを使用してください。
カスタムタイプの追加
一部のプロジェクトはワークフローに合わせてカスタムタイプを追加します。一般的な追加タイプ:
wip— 作業中(マージ前にスカッシュ)hotfix— 緊急本番修正release— リリース準備deps— 依存関係の更新
Conventional CommitsリンターのOptionsパネルでカンマ区切りの値を入力してカスタムタイプを追加できます。これらはデフォルトリストに追加されます。
タイプ検証が重要な理由
一貫したタイプにより、自動化ツールがコミットを正しく分類できます。変更ログジェネレーターは、機能、修正、ドキュメント変更の違いを知る必要があります。認識されないタイプを使用すると、コミットが誤分類されたり、変更ログから完全に除外されたりします。
ユースケース
タイプ検証は、リポジトリに到達する前にタイポや非標準タイプを早期に検出します。これは、開発者が許可されたタイプにまだ慣れていないConventional Commitsを採用するチームにとって特に重要です。