| name | cmd-commit |
| description | Git リポジトリで変更内容を確認し、適切な粒度とメッセージで安全に commit を作成するときに使う。ユーザーが「commitして」「コミット作って」「差分をコミット」「変更を分けてコミット」「この変更をコミット」などを依頼した場合に使う。git status / diff / log を確認し、未確認の変更や unrelated changes を勝手に含めず、必要に応じて commit 粒度、stage 対象、commit message を整理する。 |
Commit
目的
Git の変更内容を読み、ユーザーの意図に合う範囲だけを stage して、後から履歴を読める commit を作る。
作業ツリーにユーザーや他エージェントの変更が混在している前提で、安全に扱う。
ワークフロー
git status --short で変更ファイル、staged / unstaged / untracked の状態を確認する。git diff と git diff --staged を読み、必要に応じて git log --oneline -n 10 で既存履歴の形式を確認する。- 変更の目的、影響範囲、現在の依頼と無関係な変更の有無を判断する。
- commit 粒度を決める。複数 commit が必要なら、理由と分割案を短く提示して確認する。
- commit に含めるファイルだけを stage する。確認せずに
git add . しない。
git diff --staged で最終的に入る内容を確認する。- 既存履歴の言語と形式に合わせて commit message を作る。
git commit を実行する。git status --short で残っている変更を確認し、commit hash、message、残変更、検証状況を報告する。
絶対ルール
- ユーザーが明示していない変更を revert、削除、上書きしない。
- 読んでいない差分を commit に含めない。
- unrelated changes を commit に含めない。混在している場合は対象ファイルだけを stage する。
- untracked file は内容と必要性を確認してから stage する。
- 秘密情報、ローカル設定、生成キャッシュ、バックアップ、ログを含めない。
- pre-commit hook や commit 失敗が起きたら、出力を読み、変更されたファイルや失敗理由を確認してから次を判断する。
- 署名、amend、force push、履歴改変はユーザーが明示した場合だけ行う。
Commit 粒度
- 1つの目的にまとまる変更は 1 commit にする。
- 実装、テスト、ドキュメントが同じ目的に従属している場合はまとめてよい。
- 無関係な修正、別機能、単独のフォーマット変更、生成物更新は分ける。
- 分割したほうがよいが判断が曖昧な場合は、commit 候補と含めるファイルを示して確認する。
- ユーザーが「全部コミット」と言っても、明らかな不要物や秘密情報は含めず確認する。
Commit Message
- 既存履歴の言語、prefix、Conventional Commits などの形式を優先する。
- ユーザーが言語や形式を指定した場合はそれに従う。
- 判断材料がなければ日本語で書く。
- 1行目は変更の目的を簡潔に書く。
- commit message には必ず本文を付け、理由、主な変更、検証内容を書く。
- 「修正」「更新」「調整」だけの曖昧な件名を避ける。
- prefix、タイトル、本文フォーマットのデフォルトが必要な場合は
references/commit-message.md を読む。
確認と報告
commit 後は、次を簡潔に報告する。
- 作成した commit hash と commit message
- commit に含めた主な変更
- 実行した検証、または未実行の理由
- 残っている未コミット変更の有無
commit しなかった場合は、止めた理由、確認が必要な点、次に実行すべき操作を明示する。
