commit-work

コミット作業

目標

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

• 意図した変更のみを含める
• コミットは論理的に適切な範囲に分ける（必要に応じて分割する）
• コミットメッセージには、何が変わったのか、そしてなぜ変わったのかを記述する

確認が必要な入力（不足している場合）

• 単一のコミットか、複数のコミットか？（判断に迷う場合: 無関係な変更が含まれるときは、複数の小さなコミットにするのがデフォルトです。）
• コミットスタイル: Conventional Commits が必須です。
• その他のルール: 件名の最大長、必須のスコープなど。

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

1. ステージングの前に作業ツリーを確認する
   • git status
   • git diff（未ステージの変更）
   • 変更が多い場合: git diff --stat
2. コミットの境界を決める（必要に応じて分割する）
   • 分割の基準: 機能とリファクタリング、バックエンドとフロントエンド、フォーマットとロジック、テストとプロダクションコード、依存関係の更新と動作の変更。
   • 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
     • 空行
     • 本文（何を・なぜ。実装の経過ではなく）
     • 必要に応じてフッター（BREAKING CHANGE）
   • 複数行のメッセージにはエディタを使うことを推奨します: git commit -v
   • 役立つ場合は references/commit-message-template.md を使用します。
7. 最小限の関連検証を実行する
   • 次に進む前に、リポジトリで最も速く意味のあるチェック（ユニットテスト、リント、またはビルド）を実行します。
8. 作業ツリーがクリーンになるまで、次のコミットについて繰り返す

成果物

以下を提供します:

• 最終的なコミットメッセージ
• コミットごとの簡単な概要（何を・なぜ）
• ステージングとレビューに使用したコマンド（最低限: git diff --cached と、実行した全テスト）