スコープ付きリファクタリングコミット

スコープ付きrefactorタイプ

refactorコミットは、外部の動作を変更せずに既存のコードを再構築します。スコープと組み合わせると、コードベースのどのモジュールまたは領域がリファクタリングされたかを明確に伝えます。

例

refactor(database): replace raw SQL queries with query builder

Migrate all repository methods from string-concatenated SQL
to the Knex query builder. This improves type safety,
prevents SQL injection, and makes queries database-agnostic.

refactorを使用するタイミング

refactorは以下の場合に使用します：

• 動作を変更せずにコードを再構築する
• 関数、クラス、またはモジュールを抽出する
• 変数、関数、またはファイルの名前を変更する
• 複雑なロジックを簡素化する
• デザインパターンを適用する

以下の場合はrefactorを使用しないでください：

• バグの修正（fixを使用）
• 新機能の追加（featを使用）
• パフォーマンスの改善（perfを使用）
• フォーマットの変更のみ（styleを使用）

リファクタリングのスコープガイドライン

リファクタリングは多くのファイルに触れることが多いため、主要な変更領域を表すスコープを選択してください：

refactor(auth): extract token validation middleware
refactor(models): normalize database entity relationships
refactor(utils): split string helpers into separate modules
refactor(tests): convert callback-based tests to async/await

バージョンへの影響

リファクタリングコミットは通常、semantic-release設定でバージョンバンプをトリガーしません。コンシューマーに影響しない内部変更です。ただし、変更ログの「リファクタリング」または「コード変更」セクションに表示され、コントリビューターにとって有用です。

よくある落とし穴

• リファクタリングと機能の混在：コードをリファクタリングし、同じコミットで機能を追加する場合はfeatを使用してください。機能がより重要な変更です。
• 過度に広いスコープ：refactor(app): restructure everythingは曖昧すぎます。より小さく焦点を絞ったコミットに分割してください。