git-master

Git Master

ユーザーが Git の履歴に対する操作を依頼した場合や、Git の履歴について質問した場合に、このスキルを使用します。正確かつ慎重に、根拠に基づいて対応してください。何かを推測する前に、リポジトリの状態を確認してください。

モードの判定

まず、依頼を分類します。

• COMMIT：ローカルの変更をステージしてコミットする。
• REBASE：リベース、スカッシュ、フィックスアップ、自動スカッシュ、並べ替え、分割など、ブランチの履歴を書き換える。
• HISTORY：何を、いつ、どこで、誰が、なぜ変更したか、またはどのコミットで変更したかを調べる。
• STATUS：ブランチ、差分、作業ツリーの状態を変更せずに確認する。

ユーザーが明示的に依頼していない限り、コミット、リベース、プッシュ、強制プッシュ、リセット、stash-pop、削除を行ってはいけません。調査のみの依頼であれば、調査結果を報告して終了します。

確かな事実の確認

ツールで可能な場合は、独立した情報を並行して収集します。

git status --short
git diff --stat
git diff --staged --stat
git branch --show-current
git log -30 --oneline
git log -30 --pretty=format:%s
git rev-parse --abbrev-ref @{upstream}
git merge-base HEAD origin/main
git merge-base HEAD origin/master

アップストリームや main／master が存在しないことは珍しくありません。利用可能な最適なブランチを代わりに使うか、確認できない事実として報告します。参照の失敗を、何かの証拠として扱ってはいけません。

PR 本文の証拠添付

PR 本文にスクリーンショットやターミナルの PNG が必要な場合は、リポジトリ内の docs/reference/github-attachment-upload.md を参照してください。許可されているホスティング方法は、認証済みのウェブ添付フローによる GitHub ユーザー添付ファイルのみです。一時画像をコミットしたり、PR の証拠に GitHub Releases を使ったり、外部の画像ホストを使ったりしてはいけません。ブラウザーの Cookie、CSRF トークン、S3 フォームフィールド、アップロードヘッダーをログに記録してはいけません。

コミットモード

ユーザーが依頼した変更のみをコミットします。無関係な未コミットの作業はそのまま保持します。

1. 直近の履歴からメッセージのスタイルを確認します。ローカルで主流のパターン、言語、大文字・小文字の形式を使用します。リポジトリで使われていない限り、Conventional Commits を既定にしてはいけません。
2. ファイル名だけでなく、差分全体を確認します。ユーザーによる無関係な編集と、依頼されたコミットの対象を切り分けます。
3. 動作、モジュール、元に戻せる単位に基づいて、アトミックなグループを作成します。実装と、それに直接関係するテストは一緒にします。
4. 無関係な内容は、複数のコミットに分けることを優先します。変更ファイルが分離できない単一の動作を構成する場合、またはユーザーが明示的に単一コミットを依頼した場合に限り、1 つのコミットにまとめてもかまいません。
5. 各コミットにアトミックなグループのみが含まれるよう、パスまたはハンク単位でステージします。
6. 各コミットの前に、git diff --staged --stat と、グループの内容が適切であると確認できるだけのステージ済み差分を確認します。
7. 確認したスタイルに従ってコミットします。各コミットの後に git log -1 --oneline を確認します。

グループ分けのルール：

• 異なる機能、モジュール、生成物、設定、ドキュメント、テストのみの変更は、互いに不可分でない限り分けます。
• 生成ファイルを省くとリポジトリに不整合が生じる場合は、生成元の変更と一緒にします。
• 失敗している変更や無関係な変更を、広範なコミットに紛れ込ませてはいけません。

最終報告：コミットのハッシュ、メッセージ、未コミットで残っているファイルを一覧にします。

リベースモード

履歴の書き換えは、他者にも影響する操作です。

• ユーザーがその操作を明示的に指定していない限り、main、master、dev、リリースブランチ、保護ブランチをリベースまたは書き換えてはいけません。
• コミットがすでにプッシュされている可能性がある場合は、強制プッシュの前に確認を求めます。--force は使わず、--force-with-lease を使います。
• 作業ツリーに変更がある場合は、リベース前に意図的に保全します。変更内容を確認せずに、競合の上から stash-pop してはいけません。
• フィックスアップには、git commit --fixup=<hash> に続けて GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base> を使うことを優先します。
• 競合が発生した場合は、競合ファイルを読み、意図に沿って解決します。確認せずに ours／theirs を選んではいけません。
• リベースに失敗した場合は、まず git rebase --abort を使います。復旧方法を説明してからでなければ、reflog を使ってはいけません。

書き換え後は、関連するテスト、または少なくともプロジェクトで最も手軽なスモークチェックを実行し、ベースから HEAD までの新しいブランチ履歴を表示します。

履歴モード

質問に応じて Git ツールを選択します。

• git log -S "text"：文字列の完全一致数が変化した場合に使用します。
• git log -G "regex"：パターンに一致する行に差分があった場合に使用します。
• git blame -L start,end -- file：特定の行を最後に変更した人を調べる場合に使用します。
• git log --follow -- file：1 つのファイルの名前変更前も含めて履歴を調べる場合に使用します。
• git show <hash>：関連がありそうなコミットを確認する場合に使用します。
• git bisect：決定的な合否判定コマンドがあり、正常・異常の境界が分かっている場合に、最初の不具合コミットを見つけます。
• git reflog：最近のローカル履歴の移動を復旧または説明する場合に使用します。

回答では必ず、根拠となる正確なコマンドの情報を示します。該当する場合は、コミットハッシュ、件名、ファイルパス、行または差分のコンテキストを含めます。根拠が曖昧な場合は、何が証明されていないかを明記します。

安全性の確認

Git 履歴に書き込む前に、次の点を確認します。

• 現在のブランチが分かっている。
• 未コミットの作業を把握している。
• アップストリームへの反映状況が分かっているか、不明であることを明記している。
• 操作がユーザーの依頼に沿っている。
• 復旧手段（rebase --abort、reflog のハッシュ、または変更していない作業ツリー）が分かっている。

作業を終える前に、変更した動作または履歴操作に最も適した検証を実行します。成功したコマンドと実行できなかったコマンドを報告し、作業ツリーの状態を明記します。