commitlisted

# commit - 会話履歴ベースのコミット 会話履歴からWhyを探し出し、意味のあるコミットメッセージを生成してコミットする。 ## 手順 1. `git status` と `git diff` を実行し、変更内容を把握する 2. `git log --oneline -5` で直近のコミットスタイルを確認する 3. **会話履歴を分析**して、Whyを抽出する ### Why の抽出と分割 **Whyが複数ある場合はコミットを分ける。** - 会話履歴を遡り、ユーザーの目的・動機・課題をすべて列挙する - 異なるWhyに対応する変更は、別々のコミットに分割する - 各コミットには、そのWhyに関連するファイルだけをステージする - 例: 「バグ修正」と「新機能追加」が混在 → 2つのコミットに分ける **Whyが1つ、またはWhyが見つからない場合は1コミット。** ### メッセージ組み立てルール **優先度1: Why（なぜこの変更をしたか）** - ユーザーが最初に伝えた目的・動機・課題を探す - 例: 「バグで○○が動かない」→ `fix: ○○が動作しない問題を修正` - 例: 「パフォーマンスが遅い」→ `perf: ○○のパフォーマンスを改善` **優先度2: How（何をどう変えたか）** - Whyが見つからない場合のフォールバック - 変更内容を簡潔にまとめる - 例: `refactor: ○○のロジックをシンプルに書き換え` ### WhyとHowの判定ガイド メッセージがHowになっていないか、以下の例で確認する。 | NG（How: 手段を述べている） | OK（Why: 目的・動機を述べている） | |---|---| | `コメント追加` | `各プロパティの意味を明確化` | | `関数名変更` | `命名規則を統一` | | `ファイル分割` | `責務ごとに管理しやすくする` | | `型定義を追加` | `型安全性を向上` | | `テストを追加` | `リグレッションを防止` | **判定のコツ**: 「何をしたか」ではなく「なぜそうしたか」が伝わるかを自問する。 ### メッセージフォーマット - 1行目: 簡潔な要約（日本語OK、70文字以内） - Conventional Commits形式のprefixを付ける（feat, fix, refactor, chore, docs, perf, test） - Whyが抽出できた場合: 3行目にWhyを記載する（2行目は空行） - Whyが見つからない場合: 1行目のみでOK ``` feat: ○○機能を追加 ユーザーから○○できないという要望があったため ``` 4. コミット計画をユーザーに提示し、確認を取る - 分割する場合: 各コミットの対象ファイルとメッセージを一覧表示 - 単一の場合: メッセージのみ表示 5. 承認されたら、各コミットを順番に実行する - 対象ファイルを `git add` する（.env等の機密ファイルは除外） - `git commit` を実行する（HEREDOCでメッセージを渡す） 6. コミット結果を報告する