feat(scope): コミットへのスコープの追加
Conventional Commitsでスコープを使ってコードベースの影響を受ける領域を示す方法を学びます。命名規則、一般的なスコープ、スコープが価値を持つタイミングを解説します。
Scoped Commits
詳細な説明
Conventional Commitsでのスコープの使用
スコープは、コミットタイプの後に括弧で囲まれたオプションの名詞で、変更の影響を受けるコードベースのセクションを記述します。スコープはコミット履歴をスキャンしやすくし、プロジェクトのどの領域が変更されたかを素早く特定するのに役立ちます。
フォーマット
<type>(<scope>): <description>
メッセージの例
feat(auth): add two-factor authentication support
fix(api): handle timeout errors in payment endpoint
refactor(database): migrate from Sequelize to Prisma
一般的なスコープの命名パターン
| パターン | 例 |
|---|---|
| モジュールまたはパッケージ | auth, payments, notifications |
| レイヤー | api, ui, database, config |
| フレームワーク領域 | router, middleware, store |
| モノレポパッケージ | core, cli, web, mobile |
スコープを使うタイミング
以下の場合にスコープが最も価値を発揮します:
- プロジェクトに明確に定義されたモジュールやパッケージがある
- 複数の開発者が異なる領域で同時に作業している
- コミット履歴を領域でフィルタリングしたい(例:
git log --grep="feat(auth)") - チームが有効なスコープのセットに合意している
スコープを省略する場合
以下の場合はスコープを省略できます:
- 変更が横断的で複数の領域に均等に影響する
- プロジェクトが小さく、スコープがノイズになる
- チームがスコープの規約を確立していない
commitlintでスコープを強制する
commitlintを設定して許可されたスコープのセットを強制できます:
// commitlint.config.js
module.exports = {
rules: {
'scope-enum': [2, 'always', ['auth', 'api', 'ui', 'db', 'config']],
},
};
これにより、チーム全体でのタイプミスや一貫性のないスコープ名を防ぎます。
ユースケース
認証、決済、通知の個別モジュールを持つ大規模アプリケーションで作業しています。認証モジュールに新しいOAuthプロバイダーを追加したばかりで、git logでフィルタリングしやすいように変更が認証領域にスコープされていることを明確に示すコミットメッセージが必要です。