commit-changes

変更をコミットする際は、次のワークフローに従ってください。

このスキルでは、レビュー済みのステージ済み変更のみから、通常の新しいコミットを作成します。 マージコミットやスカッシュコミットは絶対に作成しないでください。 git merge、git merge --no-ff、git merge --squash、 git rebase --autosquash、コミットをまとめるための git commit --amend、 またはこれらに相当する履歴統合操作は実行しないでください。

1. ワークスペースを分析する：git status と git diff（ステージ済みと未ステージの両方）を実行し、すべての変更を把握します。

2. 変更を意味ごとにまとめる：作業の論理的な単位を特定します。各コミットはアトミックにし、1つのコミットにつき機能変更は1つにします。単一の関心事を実装する、関連ファイルをまとめます。

3. Conventional Commits 形式のコミットメッセージを記述する：形式は <type>(<scope>): <description> とし、必要に応じて本文を続けます。使用できるタイプ：

   • feat：新機能
   • fix：バグ修正
   • refactor：動作を変えないコード構造の変更
   • docs：ドキュメントのみの変更
   • style：フォーマット、空白、セミコロン（ロジックの変更なし）
   • test：テストの追加または更新
   • chore：ツール、設定、依存関係
   • perf：パフォーマンスの改善
   • ci：CI/CD の変更
   • build：ビルドシステムの変更
   • revert：以前のコミットの取り消し

   この形式に加えて、プロジェクト独自の規約にも従ってください。 最初のメッセージを書く前に、プロジェクトがコミットについて定めている内容（README.md の Contributing セクション、CONTRIBUTING.md、FRAMEWORK.local.md または同等のファイル）を読み、最近の git log も確認してください。 プロジェクトでは、上記の形式に加えて、すべての件名にデリバリーカードのキーを含めるなど、追加の要件がある場合があります。ドキュメントと履歴の内容が食い違う場合は、ドキュメントを優先してください。この規約の見落としは、すべてのコミットを書き終えた後に発覚し、修正するにはすべてを書き直すことになります。

4. コミットのルール：

   • 件名は1行に収めます。件名だけでは伝えきれない背景（変更の理由、採用したトレードオフ、ほかの作業への影響など）が必要な場合は、本文を追加します。件名と本文の間には空行を入れ、件名だけで十分に伝わる場合は本文を付けません。
   • 件名にも本文にも、トレーラー、共同作成者の行、AI／ツールの帰属情報、自動生成を示すマーカー、ボットの署名、AI の関与を示唆するメタデータを決して含めません。
   • コミットごとに対象を指定して git add を使います。すべての変更が1つのコミットに属する場合を除き、git add . は使いません。
   • 各コミットの直前に git diff --cached --name-only を実行し、その内容が対象のグループと一致する場合にのみコミットします。 自分のファイル名を指定しても、インデックスが自分専用になるわけではありません。git rm、git mv、前のグループの中断によってステージされた変更は、そのままステージに残るため、後から git add <one file> を実行すると、そのファイルと一緒にコミットされます。結果として2つの変更にまたがるコミットになり、コミットメッセージがそのうち1つしか説明しない状態になります。メッセージは事実に見えるため、レビューではこの問題に気づけません。
   • 各コミットの後に git log -1 --format=%B を実行し、最終的なメッセージに AI 関連の帰属情報やメタデータが含まれていないことを確認してから、git status を実行して成功を確認します。
   • この変更の編集と、他の人の無関係な未コミット作業が混在しているファイルでは、ファイル全体を含めるか除外するかを判断するのではなく、ハンク単位でステージする必要があります。 git add <file> はそのファイル内のすべてのハンクをステージするため、無関係な作業までコミットに取り込むか、自分の変更をステージせずに残すことになります。まずハンクを分離します。git diff -- <file> を実行し、@@ ヘッダーでハンクを特定してから、それらのハンクだけを含むパッチファイルに対して git apply --cached を使ってステージします（各ハンクに同じ diff --git ヘッダーが必要ですが、@@ ブロックはそれぞれ個別にします。git apply はコンテキストを使って位置を特定するため、省略したハンクによって記載行番号にずれが生じても問題ありません）。git diff --cached -- <file>（自分のハンクのみ）と git diff -- <file>（作業ツリーに残ったほかの変更のみで、未変更のまま）を実行して、分離できていることを確認します。これは仮定上の話ではなく、ある領域のすべての変更が1つの大きな共有テストファイルに集まるリポジトリで、実際に起こるケースです。

5. 実行順序：グループごとに1つずつステージしてコミットします。先のグループに進んではいけません。