commit

name	commit
description	Git の変更を安全にコミットするためのスキル。ユーザーが「コミットして」「変更をコミットしたい」「適切なコミットメッセージを作って」「変更を分割してコミットしたい」と依頼したときに使う。ブランチ確認、ステージ確認、diff 分析、論理単位でのコミット分割、Conventional Commits 形式のメッセージ作成、コミット実行、失敗した pre-commit チェックの修正までを扱う。

Commit

Git の変更をレビュー可能な単位でコミットする。

ワークフロー

Step 1: 安全なブランチであることを確認する

• ステージやコミットの前に、現在のブランチ名を確認する。
• ブランチが main または master の場合、そのブランチではコミットしない。
• 先に feature branch へ切り替える必要があることを説明し、そこで処理を止める。

Step 2: ステージ状態を確認する

• git status を実行し、staged、modified、untracked の各ファイルを把握する。
• すでに staged なファイルがある場合は、ユーザーが明示的に変更を求めない限り、その staged セットだけをコミット対象として扱う。
• staged なファイルがない場合は、依頼対象の作業に属する modified と untracked をステージしてから進める。

Step 3: メッセージを作る前に diff を読む

• 実際にコミットされる diff を確認する。
• その diff が 1 つの論理変更か、無関係な複数変更を含むかを判断する。
• 無関係な関心事が混ざっている場合は、メッセージ作成前にコミットを分割する。

コミット境界やメッセージを確定する前に references/conventional-commits.md を読む。

Step 4: 必要ならコミットを分割する

• 関心事、変更種別、レビューしやすさに基づいて分割する。
• それぞれのコミットが独立して理解できるアトミックな単位を優先する。
• 件数を増やすこと自体を目的にはせず、履歴が明確になる場合にだけ分割する。

Step 5: コミットメッセージを作成する

• Conventional Commits を使う。
• 元の依頼文ではなく、実際の diff に合う件名にする。
• 命令形で書く。
• 件名は簡潔かつ具体的に保つ。

Step 6: コミットを実行する

• 論理変更ごとに個別にコミットする。
• 通常のチェックはそのまま通す。
• ユーザーが明示的に求めない限り、--no-verify で hook を回避しない。

Step 7: hook 失敗を修正する

• pre-commit や commit 時のチェックが失敗したら、失敗内容を丁寧に読む。
• 回避策ではなく、本当の原因を修正する。
• 関連するチェックを再実行してから、コミットをやり直す。

運用ルール

• 対応する diff を読まずにコミットを作らない。
• ユーザーが件名案を出していても、実態とズレるメッセージは付けない。
• 依頼範囲より広い staged 変更がある場合、それを黙って含めない。先に指摘し、解消してからコミットする。
• 分割が必要な場合は、実行前にどう分けるかを短く説明する。