commit-smart

Smart Commit

実際の変更を分析して、意味のあるConventional Commitsを作成します。

ワークフロー

ステップ 1: 作業ツリーを確認する

現在の状態を把握するために、次のコマンドを実行します:

git status
git diff --stat
git diff --cached --stat

ステップ 2: ステージされていない変更を処理する

何もステージされていない場合（git diff --cached が空の場合）:

1. ユーザーに変更されたファイルを表示する
2. 論理的なまとまりに基づいて、ステージすべきものを提案する（例: 「これらの3つのファイルはすべて認証のリファクタリングに関連しています」）
3. すべてをステージするか、特定のファイルを選択するかを尋ねる
4. 承認されたファイルを git add <files> でステージする

すでに変更がステージされている場合は、分析に進みます。

ステップ 3: 差分を分析する

ステージされた差分全体を読み込みます:

git diff --cached

変更内容からコミットの種類を判断します:

シグナル	種類
新しい機能を持つ新規ファイル	feat
新しいテストファイルまたはテストの追加	test
既存のロジックの変更による誤動作の修正	fix
動作を変えない構造的な変更	refactor
package.json、tsconfig、CI設定の変更	chore
ビルド/バンドラー設定の変更	build
README、ドキュメント、コメントのみ	docs
フォーマット、空白、セミコロンのみ	style
パフォーマンスの改善	perf

スコープは、主に影響を受けるディレクトリまたはモジュールから判断します:

• src/api/ -> api
• src/components/auth/ -> auth
• tests/ -> tests
• ルートの設定ファイル -> スコープを省略
• 無関係な複数の領域 -> スコープを省略

ステップ 4: ユーザーによる上書きを確認する

ユーザーが $ARGUMENTS で引数を指定している場合:

• 単語1つ（例: fix）-> コミットの種類として使用
• 単語2つ（例: refactor api）-> 種類とスコープとして使用
• それ以外 -> 自動検出された値を使用

ステップ 5: コミットメッセージを作成する

形式: type(scope): imperative short description

ルール:

• 件名は最大72文字
• 命令法を使用する（「add」「fix」「refactor」など。「added」「fixes」は使わない）
• 末尾にピリオドを付けない
• 本文では、差分が示す「何を変更したか」ではなく、なぜこの変更を行ったかを説明する
• 変更が些細なもの（誤字の修正、フォーマット）の場合は、本文を省略する

例:

feat(auth): add JWT refresh token rotation

Tokens were expiring mid-session for users with slow connections.
Rotating refresh tokens extends the session without compromising
security, since each refresh token can only be used once.

ステップ 6: 確認してコミットする

提案されたコミットメッセージをユーザーに表示し、確認を求めます。

確認が取れたら、次のコマンドを実行します:

git commit -m "<message>"

その後、次のコマンドで確認します:

git log --oneline -1

コミットのハッシュとメッセージを表示します。

ヒント

• ファイルを変更するたびではなく、論理的な作業単位を完了した後に実行する
• 差分が1つのコミットには大きすぎる場合は、複数のコミットに分割することを提案する
• 破壊的変更の場合は、スコープの後に ! を付ける: feat(api)!: change response format
• 本文は「6か月後にこのコミットを読んだ人が、なぜこの変更が行われたかを理解できるか？」という問いに答えるべきである