| name | committer |
| description | Git コミットの作成を支援する。以下の場合に発動: (1) ユーザーが /commit と入力した時、(2) コード変更が完了しコミットが適切と判断した時、(3) ユーザーがコミットを依頼した時。変更内容を分析し、適切なコミットメッセージを生成してコミットを作成する。 |
コミッター
変更内容を分析し、適切なコミットメッセージでコミットを作成する。
前提条件
コミット実行前に必ず確認:
- ユーザーから明示的にコミットを依頼されている
- すべてのテストがパス
- リンター警告がゼロ
- 変更が単一の論理的な作業単位
ワークフロー
1. 状態確認
以下のコマンドを並列実行:
git status # 変更ファイル一覧
git diff --staged # ステージ済み変更
git diff # 未ステージ変更
git log --oneline -5 # 直近のコミットスタイル確認
2. 変更の分析
| 確認項目 | チェック内容 |
|---|---|
| 変更の種類 | 新機能、バグ修正、リファクタリング、ドキュメント、テストなど |
| 影響範囲 | 変更されたファイル、モジュール、機能 |
| 目的 | なぜこの変更が必要か |
3. コミットメッセージ作成
原則:
- 「何を」ではなく「なぜ」を重視
- 1〜2文で簡潔に
- リポジトリの既存スタイルに合わせる
言語選択:
- リポジトリの既存コミットが日本語 → 日本語
- リポジトリの既存コミットが英語 → 英語
- 混在または不明 → ユーザーに確認
良いメッセージの例:
ユーザー認証のセッションタイムアウトを修正
セッションが24時間で切れる問題を解決。
タイムアウト値を設定可能にした。
避けるべき例:
fix bug # 何を修正したか不明
Update files # 具体性がない
WIP # 作業途中をコミットしない
4. コミット実行
# 関連ファイルをステージング
git add <files>
# HEREDOC でメッセージを渡す（フォーマット維持のため）
git commit -m "$(cat <<'EOF'
コミットメッセージ
詳細説明（必要な場合）
EOF
)"
# 成功確認
git status
コミット単位
変更は以下の 2 種類に明確に分離します：
構造変更（Structural Changes）
- コードの配置・整理・フォーマット
- 動作は一切変更しない
- 例：メソッドの並び替え、インポート整理、変数名変更
動作変更（Behavioral Changes）
- 機能の追加・修正・削除
- テスト結果が変わる変更
- 例：新機能追加、バグ修正、ロジック変更
重要：構造変更と動作変更を同一コミットに含めない
禁止事項
以下は絶対に行わない:
--forceオプションの使用--no-verifyでフック回避- 機密情報（.env、credentials など）のコミット
- main/master への直接プッシュ
- ユーザーの明示的な依頼なしのコミット
git commit --amendの使用（特別な条件を除く）
--amend の使用条件
以下のすべてを満たす場合のみ使用可能:
- ユーザーが明示的に amend を要求、または pre-commit hook が自動修正したファイルを含める必要がある
- HEAD コミットがこの会話中に自分が作成したもの
- コミットがリモートにプッシュされていない
確認方法:
git log -1 --format='%an %ae' # 作成者確認
git status # "Your branch is ahead" を確認
リソース
- references/commit-guidelines.md - コミットメッセージのベストプラクティス詳細