バッチでコミットする
未コミットの作業を論理的なコミットに分割します。各コミットは独立してレビュー可能で、そのスライスに必要なすべてのファイルを含んでいる必要があります。
安全対策(常に)
- git config を更新しないでください。
- ユーザーが明示的に要求しない限り、強制プッシュ、ハードリセット、その他の破壊的な git 操作は行わないでください。
- ユーザーが明示的に要求しない限り、フックをスキップしないでください(
--no-verifyなど)。 - シークレット(
.env、認証情報、鍵)をステージングしないでください。警告し、除外します。 - ユーザーの修正ルールが完全に満たされない限り、
git commit --amendを使用しないでください。 - コミットフックが失敗した場合は、問題を修正して新しいコミットを作成してください。失敗したコミットを修正しないでください。
- コミットメッセージに
Co-authored-by: Cursorを追加しないでください。
1. 調査
可能な場合は並行して実行します:
git statusgit diffおよびgit diff --stagedgit log -5 --onelineメッセージスタイルの確認用git remote -vおよびブランチ追跡(git status -sb)
コミットするものがない場合は、その旨を伝えて停止します。
2. バッチを計画する
変更を目的ごとにグループ化します。ファイルタイプだけに基づかないでください。例:
- 1つの機能またはユーザー向けの動作とそのテスト、ドキュメント
- 1つのバグ修正とそれを修正するファイルのみ
- 独立したリファクタリング(無関係な機能を混在させない)
- 1つの領域にスコープされた雑務やツール(依存関係、CI、設定)
ルール:
- 1つのコミットに無関係な機能を混在させないでください。
- 同じバッチに付随ファイルを含めます(例:1つの変更に対するスキーマ + エンティティ + マイグレーション + 呼び出し箇所)。
- ファイルが2つの関心事に触れている場合は、主要なバッチを優先するか、コミット前にトレードオフを説明してください。
- バッチを順番にリストします:基本(共有型、設定)、次に機能、最後にドキュメント(先行コミットに依存する場合のみ)。
ユーザーに簡潔な計画を表示します:バッチ番号、ファイルまたはパス、提案する従来のコミット件名。その後、ユーザーが反対しない限り進めます。
3. 各バッチをコミットする
各バッチに対して、順次:
- そのバッチのみをステージングします(
git addで特定のパスを指定。ツリー全体が1つのバッチでない限りgit add -Aは避けます)。 git diff --stagedで無関係なものが混入していないか再確認します。- なぜに焦点を当てた従来のコミット件名(
feat、fix、chore、docs、refactor、testなど)を記述します。 - ブランチ名に課題 ID が含まれている場合は、件名に
#<issue>を追加します(GitLab スタイル)。 - コミットします。Windows PowerShell では
git commit -m '件名'(または短い本文のために複数の-m)を使用します。bash では、メッセージに HEREDOC を使用しても構いません。 - 対象の変更に対してワーキングツリーがクリーンになるまで繰り返します。
4. GitHub(またはリモート)にプッシュする
すべてのバッチが終わったら:
origin(またはユーザーの指定したリモート)が存在し、ブランチを公開すべき場合は、上流がないときはgit push -u origin HEADを実行し、それ以外はgit pushを実行します。mainまたはmasterに強制プッシュしないでください。- プッシュが拒否された場合は、エラーを報告し、pull/rebase を提案します。ユーザーが明示的に要求しない限り、強制プッシュは行いません。
- リモートがない場合は、コミットはローカルのみであると伝え、リモートを追加するかどうかを尋ねます。
5. 報告
要約:
- 各コミットのハッシュと件名(最新を最後に、または番号付きリスト)。
- プッシュ結果(利用可能な場合は URL またはブランチ)。
- 意図的にステージングされていないもの(シークレット、ローカル専用ファイル)。
commit-msg との関係
commit-msg はすでにステージングされたファイルから1行を提案するだけで、コミットはしません。このスキルは計画、ステージング、複数ステップでのコミット、プッシュを行います。