コミット作業

目標

レビューしやすく、安全にリリースできるコミットを作成する:

• 意図した変更のみが含まれている
• コミットが論理的にスコープされている（必要に応じて分割）
• コミットメッセージが何が変更され、なぜ変更されたかを説明している

確認すべき入力情報（不足している場合）

• 単一コミットか複数コミットか?（不明な場合: 無関連な変更がある場合は複数の小さなコミットがデフォルト）
• コミットスタイル: Conventional Commits は必須
• ルール: 件名の最大文字数、必須スコープなど

ワークフロー（チェックリスト）

1. ステージング前にワーキングツリーを確認
   • git status
   • git diff（ステージ前）
   • 変更が多い場合: git diff --stat
2. コミット境界を決定（必要に応じて分割）
   • 分割基準: フィーチャー vs リファクタリング、バックエンド vs フロントエンド、フォーマット vs ロジック、テスト vs 本番コード、依存関係の更新 vs 動作の変更
   • 1つのファイルに混在した変更がある場合は、パッチステージングの使用を計画
3. 次のコミットに属するものだけをステージング
   • 混在した変更の場合はパッチステージングを推奨: git add -p
   • ハンク/ファイルをアンステージするには: git restore --staged -p または git restore --staged <path>
4. 実際にコミットされる内容をレビュー
   • git diff --cached
   • 健全性チェック:
     • シークレットやトークンが含まれていない
     • 誤ったデバッグログがない
     • 無関係なフォーマット変更がない
5. ステージした変更を 1-2 文で説明（メッセージを書く前に）
   • 「何が変更されたか?」+ 「なぜ?」
   • うまく説明できない場合は、コミットが大きすぎるか混在している可能性があります。ステップ 2 に戻ってください
6. コミットメッセージを作成
   • Conventional Commits を使用（必須）:
     • type(scope): short summary
     • 空行
     • body（何/なぜ、実装日記ではない）
     • footer（BREAKING CHANGE）必要に応じて
   • 複数行メッセージはエディタを推奨: git commit -v
   • 必要に応じて references/commit-message-template.md を使用
7. 最小限の関連する検証を実行
   • 次に進む前に、リポジトリの最速で意味のあるチェック（ユニットテスト、lint、またはビルド）を実行してください
8. ワーキングツリーがクリーンになるまで次のコミットを繰り返す

成果物

以下を提供してください:

• 最終的なコミットメッセージ（複数の場合）
• コミットごとの簡潔なサマリー（何/なぜ）
• ステージング/レビューに使用したコマンド（最小限: git diff --cached, プラス実行したテスト）