Agent-almanac commit-changes
install
source · Clone the upstream repo
git clone https://github.com/pjt222/agent-almanac
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/ja/skills/commit-changes" ~/.claude/skills/pjt222-agent-almanac-commit-changes-7ad6f5 && rm -rf "$T"
manifest:
i18n/ja/skills/commit-changes/SKILL.mdsource content
変更のコミット
ファイルを選択的にステージし、明確なコミットメッセージを記述し、コミット履歴を確認する。
使用タイミング
- 論理的な作業単位をバージョン管理に保存する時
- 説明的なコンベンショナルメッセージでコミットを作成する時
- 直近のコミットを修正する時(メッセージまたは内容)
- コミット前にコミット対象を確認する時
入力
- 必須: コミット対象の変更されたファイル(1つ以上)
- 任意: コミットメッセージ(未指定の場合は自動で下書きを作成)
- 任意: 直前のコミットを修正するかどうか
- 任意: 共同著者の帰属情報
手順
ステップ1: 現在の変更を確認する
ワーキングツリーのステータスを確認し、差分を調べる:
# 変更済み、ステージ済み、未追跡のファイルを確認 git status # ステージされていない変更を表示 git diff # ステージされた変更を表示 git diff --staged
期待結果: 変更済み、ステージ済み、未追跡のすべてのファイルが明確に把握できる。
失敗時:
git status が失敗する場合、gitリポジトリ内にいることを確認する(git rev-parse --is-inside-work-tree)。
ステップ2: ファイルを選択的にステージする
機密ファイルや無関係な変更を誤って含めないよう、
git add . や git add -A ではなく特定のファイルを指定してステージする:
# ファイル名を指定してステージ git add src/feature.R tests/test-feature.R # 特定のディレクトリ内の全変更をステージ git add src/ # ファイルの一部を対話的にステージ(非対話的コンテキストでは非対応) # git add -p filename
コミット前にステージ内容を確認する:
git diff --staged
期待結果: 意図したファイルと変更のみがステージされている。
.env、認証情報、大容量バイナリは含まれていない。
失敗時: 誤ってステージしたファイルは
git reset HEAD <file> で解除する。機密データをステージしてしまった場合は、コミット前にただちに解除する。
ステップ3: コミットメッセージを記述する
コンベンショナルコミットのフォーマットを使用する。正しいフォーマットのため、必ずHEREDOCでメッセージを渡す:
git commit -m "$(cat <<'EOF' feat: add weighted mean calculation Implements weighted_mean() with support for NA handling and zero-weight filtering. Includes input validation for mismatched vector lengths. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> EOF )"
コンベンショナルコミットのタイプ:
| タイプ | 使用場面 |
|---|---|
| 新機能 |
| バグ修正 |
| ドキュメントのみ |
| テストの追加・更新 |
| 修正でも機能追加でもないコード変更 |
| ビルド、CI、依存関係の更新 |
| フォーマット、空白(ロジック変更なし) |
期待結果: 何をではなくなぜを説明する、説明的なメッセージのコミットが作成される。
失敗時: pre-commitフックが失敗した場合、問題を修正し、
git add で再ステージし、新しいコミットを作成する(失敗したコミットは作成されていないため --amend は使わない)。
ステップ4: 直前のコミットを修正する(任意)
共有リモートにプッシュしていない場合のみ修正する:
# メッセージのみ修正 git commit --amend -m "$(cat <<'EOF' fix: correct weighted mean edge case for empty vectors EOF )" # 追加のステージ変更と合わせて修正 git add forgotten-file.R git commit --amend --no-edit
期待結果: 直前のコミットがその場で更新される。
git log -1 で修正内容が確認できる。
失敗時: コミットが既にプッシュ済みの場合は修正しない。代わりに新しいコミットを作成する。共有ブランチへの修正済みコミットの強制プッシュは履歴の乖離を引き起こす。
ステップ5: コミットを確認する
# 直前のコミットを表示 git log -1 --stat # 最近のコミット履歴を表示 git log --oneline -5 # コミット内容を確認 git show HEAD
期待結果: 正しいメッセージ、著者、ファイル変更でコミットが履歴に表示される。
失敗時: コミットに誤ったファイルが含まれている場合、
git reset --soft HEAD~1 でコミットを取り消し(変更はステージされたまま保持)、正しく再コミットする。
バリデーション
- コミットに意図したファイルのみが含まれている
- 機密データ(トークン、パスワード、
ファイル)がコミットされていない.env - コミットメッセージがコンベンショナルコミットのフォーマットに従っている
- メッセージ本文で変更の理由が説明されている
-
で正しいメタデータのコミットが表示されるgit log - pre-commitフック(存在する場合)がパスしている
よくある落とし穴
- 一度にコミットしすぎる: 各コミットは1つの論理的な変更を表すべき。無関係な変更は別のコミットに分割する。
を無確認で使う: 必ず先にgit add .
を確認する。ファイル名を指定してステージすることを推奨。git status- プッシュ済みコミットの修正: 共有ブランチにプッシュ済みのコミットは絶対に修正しない。履歴の書き換えは共同作業者に問題を引き起こす。
- 曖昧なコミットメッセージ: 「fix bug」や「update」では何も伝わらない。何を変更し、なぜ変更したかを記述する。
- 内容修正時の
忘れ: 直前のコミットに忘れたファイルを追加する時は、既存のメッセージを保持するために--no-edit
を使う。--no-edit - フック失敗後の
使用: pre-commitフックが失敗した場合、コミットは作成されていない。--amend
を使うと前のコミットを変更してしまう。フック問題の修正後は必ず新しいコミットを作成する。--amend
関連スキル
- コミット前のブランチワークフローmanage-git-branches
- コミット後の次のステップcreate-pull-request
- マージ/リベース時のコンフリクト処理resolve-git-conflicts
- リポジトリの設定と規約configure-git-repository