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.md
source 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
)"

コンベンショナルコミットのタイプ:

タイプ使用場面
feat
新機能
fix
バグ修正
docs
ドキュメントのみ
test
テストの追加・更新
refactor
修正でも機能追加でもないコード変更
chore
ビルド、CI、依存関係の更新
style
フォーマット、空白(ロジック変更なし)

期待結果: 何をではなくなぜを説明する、説明的なメッセージのコミットが作成される。

失敗時: 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
    を使う。
  • フック失敗後の
    --amend
    使用
    : pre-commitフックが失敗した場合、コミットは作成されていない。
    --amend
    を使うと前のコミットを変更してしまう。フック問題の修正後は必ず新しいコミットを作成する。

関連スキル

  • manage-git-branches
    - コミット前のブランチワークフロー
  • create-pull-request
    - コミット後の次のステップ
  • resolve-git-conflicts
    - マージ/リベース時のコンフリクト処理
  • configure-git-repository
    - リポジトリの設定と規約