---

name: commit-changes description: > ファイルのステージング、コミット、修正をコンベンショナルコミットメッセージで行う。 変更のレビュー、選択的ステージング、HEREDOCフォーマットによる説明的な コミットメッセージの作成、コミット履歴の確認をカバーする。論理的な作業単位を バージョン管理に保存する時、コンベンショナルメッセージでコミットを作成する時、 直近のコミットを修正する時、コミット前にステージされた変更を確認する時に使用する。 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: git complexity: basic language: multi tags: git, commit, staging, conventional-commits, version-control locale: ja source_locale: en source_commit: 6a868d56 fence_basis_commit: 6a868d56 translator: Claude Opus 4.6 translation_date: 2026-03-13

変更のコミット

ファイルを選択的にステージし、明確なコミットメッセージを記述し、コミット履歴を確認する。

使用タイミング

• 論理的な作業単位をバージョン管理に保存する時
• 説明的なコンベンショナルメッセージでコミットを作成する時
• 直近のコミットを修正する時（メッセージまたは内容）
• コミット前にコミット対象を確認する時

入力

• 必須: コミット対象の変更されたファイル（1つ以上）
• 任意: コミットメッセージ（未指定の場合は自動で下書きを作成）
• 任意: 直前のコミットを修正するかどうか
• 任意: 共同著者の帰属情報

手順

ステップ1: 現在の変更を確認する

ワーキングツリーのステータスを確認し、差分を調べる:

# See which files are modified, staged, or untracked
git status

# See unstaged changes
git diff

# See staged changes
git diff --staged

期待結果: 変更済み、ステージ済み、未追跡のすべてのファイルが明確に把握できる。

失敗時: git status が失敗する場合、gitリポジトリ内にいることを確認する（git rev-parse --is-inside-work-tree）。

ステップ2: ファイルを選択的にステージする

機密ファイルや無関係な変更を誤って含めないよう、git add . や git add -A ではなく特定のファイルを指定してステージする:

# Stage specific files by name
git add src/feature.R tests/test-feature.R

# Stage all changes in a specific directory
git add src/

# Stage parts of a file interactively (not supported in non-interactive contexts)
# 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: 直前のコミットを修正する（任意）

共有リモートにプッシュしていない場合のみ修正する:

# Amend message only
git commit --amend -m "$(cat <<'EOF'
fix: correct weighted mean edge case for empty vectors

EOF
)"

# Amend with additional staged changes
git add forgotten-file.R
git commit --amend --no-edit

期待結果: 直前のコミットがその場で更新される。git log -1 で修正内容が確認できる。

失敗時: コミットが既にプッシュ済みの場合は修正しない。代わりに新しいコミットを作成する。共有ブランチへの修正済みコミットの強制プッシュは履歴の乖離を引き起こす。

ステップ5: コミットを確認する

# View the last commit
git log -1 --stat

# View recent commit history
git log --oneline -5

# Verify the commit content
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 - リポジトリの設定と規約