コミットメッセージ規約
このドキュメントは、Rin プロジェクトのコミットメッセージ規約を概説します。これらの規約に従うことで、変更履歴とリリースノートを自動的に生成できます。
形式
各コミットメッセージは次の形式に従う必要があります:
タイプ
スコープ
スコープは任意で、影響を受けるコードベースの領域を示す必要があります:
api- バックエンド API の変更client- フロントエンド/クライアントの変更db- データベースの変更auth- 認証関連ui- UI コンポーネントdeps- 依存関係config- 設定ファイルdocs- ドキュメントrelease- リリース関連
サブジェクト
- 命令形を使用する(「added」や「adds」ではなく「add」)
- 最初の文字を大文字にしない
- 末尾にピリオドを付けない
- 最大 50 文字
良い例:
feat(auth): add password reset functionalityfix(api): handle null response from databasedocs(readme): update installation instructions
悪い例:
feat: Added new feature(過去形、大文字)fix: fixed the bug.(過去形、末尾にピリオド)update stuff(タイプなし、曖昧な説明)
本文
- 命令形を使用する
- 72 文字で折り返す
- 何を、なぜを説明し、どのようには説明しない
- サブジェクトとは空行で区切る
例:
フッター
- Issue と PR を参照する:
Closes #123、Fixes #456 - 破壊的変更:
BREAKING CHANGE: description
例:
例
機能
バグ修正
ドキュメント
破壊的変更
コミットメッセージのリンティング
これらの規約を強制するために commitlint の使用を推奨します:
なぜ?
- 自動変更履歴:リリースノートを自動生成できる
- 明確な履歴:何が、なぜ変更されたかを理解しやすい
- セマンティックバージョニング:バージョンアップの判断に役立つ(feat=minor、fix=patch、breaking=major)
- より良いコラボレーション:一貫した形式でレビューが容易になる
ツール
-
Commitizen:対話式コミットメッセージビルダー
-
VS Code 拡張機能:オートコンプリート用の「Conventional Commits」
質問がありますか?
コミットタイプや形式について不明な場合は、PR で質問するか、リポジトリ内の既存のコミットを参照してください。