commit

スコープ外の変更を保持しながら、まとまりのあるコミットをちょうど 1 つ作成してください。コミットメッセージは英語で記述し、ユーザーにはユーザーの言語で伝えてください。以下のデフォルトよりも、ユーザーの明示的な指示と適用されるリポジトリのガイダンスを優先してください。

リポジトリのコンテキスト

• 状態：!git status --short
• ステージ済みの変更：!git diff --cached
• ステージされていない変更：!git diff
• 未追跡のファイル：!git ls-files --others --exclude-standard
• マージされていないファイル：!git diff --name-only --diff-filter=U
• 現在のブランチ：!git branch --show-current
• 最近のコミット：!git log --oneline -10

1. コミットのスコープを決める

1. 作業ツリーとインデックスに変更がない場合は、コミットするものがないことをユーザーに伝え、そこで終了してください。
2. 対象の変更を次の順序で選択してください。
   • ユーザーがファイルまたは論理的な変更を指定している場合は、そのスコープを使用してください。無関係な変更がすでにステージされている場合は、インデックスを変更する前に、競合する内容を説明して進め方を確認してください。
   • それ以外で、ステージ済みの変更がある場合は、ステージ済みの差分全体を対象としてください。ステージされていない変更と未追跡の変更には手を加えないでください。
   • それ以外の場合は、ステージされていない変更と未追跡の変更を目的ごとにグループ化してください。明確にひとまとまりの論理的な変更であれば、そのグループを対象としてください。複数のグループが考えられる場合、またはファイルを含めるかどうかが曖昧な場合は、グループを提示して、どれをコミットするか確認してください。
3. まとまりがあるかどうかは、ファイル数だけでなく、動作と目的に基づいて判断してください。実装に直接関連するテスト、ドキュメント、設定は、実装と一緒に含めてください。

2. インデックスを準備する

対象がすでにすべてステージされている場合を除き、明示的なパス指定を使って対象のファイルのみをステージしてください。

git add -- "path/with[brackets]/file.ts" "another path/file.md"

パスの前には -- を付け、スペース、角括弧、丸括弧、ワイルドカードなどのシェル特殊文字を含むパスは引用符で囲んでください。対象の変更に含まれる場合に限り、未追跡のファイルも含めてください。リポジトリのガイダンスで明示的に追跡されており、変更に必要な場合を除き、ローカル設定、認証情報、一時ファイル、ログ、ビルド生成物は除外してください。対象のファイルに関連するハンクと無関係なハンクが混在している場合は、関連するハンクのみをステージしてください。安全に部分ステージできない場合は、ファイル全体をステージする前にユーザーに確認してください。

ステージ後、git status --short と git diff --cached を再実行してください。これ以降、コミットの判断にはステージ済みの差分のみを使用してください。

3. ステージ済みの差分を確認する

次のいずれかの阻害要因がある場合は、コミットする前に作業を止めてください。

条件	必要な対応
ステージ済みの差分が空である	このコミットのためにステージされた変更がないことをユーザーに伝えてください。
マージ未解決の項目または実際の競合マーカーがある	該当するファイルを列挙し、解決するようユーザーに依頼してください。
シークレット、認証情報、秘密鍵、または意図しない .env ファイルが疑われる	値を繰り返さず、場所を特定して、削除するか、シークレットではないテストデータであることを確認するようユーザーに依頼してください。
ステージ済みの内容が不明瞭、または無関係である	何がスコープと一致しないかを説明し、コミット対象をどうするか確認してください。

追加された行も確認し、意図しないデバッグ文、生成された出力、ログ、説明のない TODO または FIXME マーカーがないか調べてください。意図しない項目と思われる場合にのみ確認してください。出現するたびに問題として扱う必要はありません。

4. メッセージを作成する

メッセージは、差分を確認しない可能性のある人間やコーディング エージェントに向けた、簡潔で単独で意味が通る説明として扱います。 作成者の作業内容、ファイル一覧、実装の詳細よりも、変更された動作や システムルールを優先してください。すべての主張は、ステージ済みの 変更と関連するリポジトリのコンテキストに基づいてください。

まず、リポジトリで明示されているコミット規約に従ってください。 最近のコミット履歴は補足的な根拠として使い、記述されたガイダンスの 代わりにはしないでください。次に、以下を整理します。

1. 動作、機能、データフロー、またはシステムルールにおける、 変更前と変更後の主な違い。
2. ステージ済みの差分の大部分を説明する、単一の中核となる考え方。
3. 読者が誤った認識を持たないために必要なコンテキストのみ。

規約が定められていない場合は、以下を既定のルールとします。

• タイトル（件名）： 変更された概念と、その動作または適用ルールを 示す、命令形の英語の動詞から始めます。単なる編集作業や広範な効果 ではなく、対象と変更内容を明示してください。Update retry handling よりも Deduplicate retries by request ID を優先します。末尾に句点を 付けず、簡潔にまとめ、72 文字を超えないようにしてください。 conventional commit のタイプやスコープ（feat:、fix(x):）、 チケット番号や課題番号、ブランチ名は含めません。最近のコミットに このような接頭辞が含まれていても、記述された明示的な規約 （例：CONTRIBUTING.md、コミットテンプレート、commitlint の設定）が ない限り、追加する理由にはなりません。
• 説明（本文）： 既定では、変更内容を読者が確認できる形で述べる 最初の文を含む、短い段落を 1 つにします。つまり、以前の状態と現在の 状態を示します。Previously, <old rule>. Now, <new rule>. は自然な 形式の 1 つですが、必須ではありません。新しい機能、ファイル、 初版など、意味のある以前の動作が存在しない場合は、新しいルールを 直接述べてください。「以前は」という節で「現在」の節を否定するだけ の対比は書かないでください。決定に関わる単位、方向、または変更され ない範囲が差分の一部である場合に限り、それを含めます。タイトルだけ で変更内容を把握できる場合に限り、本文を省略します。ファイルや テストの概要は書きません。
• 具体的な入力、状態、出力を示すと、わかりにくいルールをより早く 理解できる場合は、最小限の例を 1 つだけ使います。例： Attempts r1, r1, r2 now create two jobs instead of three because request ID defines identity. 例は差分に忠実にし、裏付けのない動作を作り出さないでください。
• 中核となる考え方を示した後、変更の理解や対応に実質的に役立つ場合 に限り、動機、重要な制約やトレードオフ、互換性を損なう変更、 移行ガイダンスを含めます。
• 説明はタイトルの後に空行を挟んで記載し、本文の各行は 72 文字以内に 収めます。

説明を、ファイルごとや差分のまとまりごとの要約にしないでください。 中核となる認識を変えない二次的な編集、通常のテスト、機械的な詳細は 省略します。変更量だけを理由に、本文や具体例を無理に含めないで ください。

5. 確認してコミットする

コミットを実行する前に、最後に git diff --cached を確認し、次の点を検証してください。

1. ステージ済みのすべての変更が、選択したスコープに含まれていること。
2. メッセージが、ファイルごとの確認を必要とせず、未ステージの作業について主張することもなく、ステージ済みの変更の本質を正確に伝えていること。
3. ステージ済みの差分が、上記の安全性レビューに引き続き合格していること。

件名のみのメッセージの場合は、次を実行します。

git commit -m "Subject line"

本文付きのメッセージの場合は、Git が実際の空行を挿入するように、個別の -m 引数を使用します。長い本文には実際の改行を入れ、リテラルの \n 文字列として記述しないでください。

git commit \
  -m "Deduplicate retries by request ID" \
  -m "Retries now treat request ID as the unit of identity. Attempts r1, r1,
r2 create two jobs instead of three."

コミットに失敗した場合は、以降の操作を行う前に、エラーと現在のステータスを確認してください。フックがファイルまたはインデックスを変更した場合は、新しいステージ済みの差分を確認し、再試行する前にメッセージを再検証してください。失敗した操作をむやみに再試行しないでください。

成功したら、git log -1 --format='%B' で保存されたメッセージ全体を確認してください。タイトルと本文の区切り、および本文の改行が、リテラルの \n 文字列ではなく、実際の改行であることを検証してください。作成したメッセージに誤りがある場合は、実際の改行を使って修正し、もう一度確認してください。次に、git log -1 --format='%h %s' と git status --short を実行します。コミットハッシュと件名を報告し、未ステージまたは未追跡の変更が残っていれば、そのことも伝えてください。ユーザーから別途依頼されていない限り、プッシュしないでください。