kentanakae/git-commit

Step 1: 変更状況の確認

1. git status でワーキングツリーの状態を確認する
2. git diff --staged でステージ済みの変更を確認する
3. ステージ済みの変更がない場合:
   • git diff と git status の結果を元に、未ステージの変更内容を表示する
   • どのファイルをステージすべきか提案する
   • ユーザーの確認を得てから git add を実行する

変更が何もない場合は、その旨を伝えて終了する。

Step 2: 差分分析と分割判断

ステージ済みの差分を分析し、論理的に独立した変更単位が複数含まれていないか判断する。

分割の判断基準

• 異なる機能・目的の変更が混在している（例: 機能追加とバグ修正）
• 無関係なファイル群の変更がまとまっている
• リファクタリングと機能変更が混在している

分割が不要な場合

単一の目的に沿った変更のみであれば、分割せずに Step 3 へ進む。

分割が推奨される場合

分割案をユーザーに提示する:

分割提案:
1. コミット1: [目的] — [対象ファイル一覧]
2. コミット2: [目的] — [対象ファイル一覧]
...

ユーザーが承認したら、各コミットについて Step 3〜5 を順番に繰り返す。 ユーザーが分割不要と判断したら、全体を1つのコミットとして Step 3 へ進む。

Step 3: コミットメッセージの生成

$ARGUMENTS が渡されている場合はそれをコミットメッセージとして使用し、Step 4 へ進む。

渡されていない場合は、対象の差分を分析し、以下のフォーマットでコミットメッセージを 3つ 提案する:

{JIRAチケットキー} コミットタイトル

- 変更内容の箇条書き説明
- 変更内容の箇条書き説明

ルール

• JIRAチケットキー（例: PROJ-123）はブランチ名から推測できる場合のみ含める。推測できない場合は省略する
• タイトルは変更の要約を簡潔に書く（50文字以内目安）
• 箇条書きで具体的な変更内容を列挙する
• 日本語で記述する

Step 4: ユーザー確認

提案した3つのコミットメッセージをユーザーに提示し、以下を確認する:

• どのメッセージを使うか（または修正内容）
• コミットして良いか

Step 5: コミット実行

ユーザーの確認後、git commit -m "メッセージ" を実行する。

分割コミットの場合:

1. 現在のコミット分のファイルのみをステージ（git add で対象ファイルを指定）
2. コミットを実行
3. 次のコミットの Step 3 へ戻る
4. 全コミット完了後、git log --oneline で結果を報告する

単一コミットの場合:

• コミット完了後、結果を簡潔に報告する。