コロン後の空の説明

空の説明がConventional Commits検証に失敗する理由。コロン区切りの後には意味のあるテキストが含まれている必要があります。

Common Mistakes

詳細な説明

空でない説明ルール

Conventional Commitメッセージでは、: 区切りの後に空でない説明が必要です。説明はコミットメッセージの最も重要な部分で、読者にコミットが何をするかを伝えます。

無効な例

feat:

または

fix(auth):

どちらも説明が空です。タイプと区切りは正しくても、説明がないとコミットメッセージは不完全です。

有効な例

feat: add dark mode toggle
fix(auth): prevent session hijacking via expired tokens
refactor: extract validation logic into shared utility

効果的な説明の書き方

良い説明のためのガイドライン:

  1. 命令形を使用:「add」「fix」「update」であり、「added」「fixes」「updating」ではありません。
  2. 小文字で始める:「add feature」であり「Add feature」ではありません。
  3. 末尾にピリオドなし:「add feature」であり「add feature.」ではありません。
  4. 具体的に:「fix null pointer in user lookup」は「fix bug」よりも優れています。
  5. 短く保つ:説明部分は50文字未満を目指してください(件名行全体は72文字未満)。

ツールが空の説明を拒否する理由

変更ログジェネレーターは、生成された変更ログの箇条書きテキストとして説明を使用します。空の説明は意味のない変更ログエントリを生成します。バージョンバンパーは、コミットがリリースをトリガーするのに十分な意味を持つかどうかを判断するために説明が必要です。CIリンターはこれらの問題を防ぐためにコミットを拒否します。

よくある原因

  • git commit -m "feat:"で急いでコミット
  • IDEのコミットダイアログがタイプを自動入力するが、開発者が説明を追加し忘れる
  • テンプレートをコピー&ペーストして説明を埋め忘れる

ユースケース

空の説明チェックは、意味のないコミットメッセージがリポジトリに入ることを防ぎます。すべてのコミットが明確な要約を持つことを保証し、これは読みやすいGit履歴、有用な変更ログ、効果的なコードレビューに不可欠です。

試してみる — Conventional Commits Linter

フルツールを開く