Git の安全な操作

部分 stage と整形

1. git diff --cached と git diff で、今回含める変更と残す変更を確認する。対話操作が使えなければ、対象 hunk だけのパッチを git apply --cached で適用し、両方の差分を再確認する。作業ツリーを変えずにコミットの境界を保てる。
2. 整形フックでは git diff --quiet -- <path> の終了コードを調べる。0 は index と作業ツリーの一致、1 は未 stage の変更を示し、それ以外はエラーとして扱う。部分 stage の検査には git show :<path> の内容を使い、oxfmt なら --stdin-filepath <path> で得た整形結果と比較する。作業ツリーへの --check ではコミットされる内容を検査できない。非対応形式を除外する場合も診断文を照合し、構文エラーと区別する。
3. 整形はプロジェクトのスクリプト経由で対象ファイルに実行する。大きな整形差分を内容変更と別のコミットにすると、変更理由を追いやすい。全体整形のフックがある場合は実行前後の差分を比べ、並行作業のファイルに及んだ変更も担当セッションと確認し、最終状態で検査する。
4. 各コミットの実装と設定の整合性を検査し、コメントとコミット本文がその時点でも正しいか確認する。最終状態で通っても、中間のコミットが単独で通るとは限らない。署名で失敗した場合は検査の失敗と区別して報告し、index を確認して次の変更群を混ぜない。
5. 整形用の Codex 許可規則では、prefix_rule にスクリプト名と必要なフラグまで引数ごとに列挙する。lint は lint:fix に一致せず、bun run だけでは別のスクリプトも許可する。justification には読み取り専用か、ファイルを書き換えるかを明記する。整形の CI 検査を追加した場合は、集約ジョブのトリガーと必須ワークフロー一覧にも登録する。集約されなければ失敗してもマージを阻止しない。

並行セッションの作業場所

1. pwd と git rev-parse --show-toplevel --git-dir --git-common-dir の出力を照合する。追加 worktree の git-dir は本体の .git/worktrees/<name> を指すため、作業ファイルと管理情報の場所を区別できる。委譲時はツールの --cwd <worktree> などに絶対パスを渡し、起動後の cwd も確認する。親セッションの cd を引き継ぐとは限らない。
2. 土台の調査には git log <base> のように参照を明示し、git log <base>..<branch> で流入するコミットを確認する。現在の HEAD から新規ブランチを作る前に起点の SHA を確かめると、別セッションのブランチや rebase 中の detached HEAD を誤って土台にしない。
3. 土台の SHA が変わった場合は、件名だけで同じ履歴と判断せず、最新の土台との関係を確認する。方針に沿って土台へ載せ直したら検査し、fast-forward を再試行する。検査中にも土台が動き得るため、--ff-only の失敗を強制更新へ切り替えない。マージ後にローカルのブランチ切り替えや同期まで行うコマンドは、使用中の checkout への影響も確認する。
4. 削除前には使用中のプロセスも調べる。Linux なら /proc/<pid>/cwd で対象 worktree 内を指すプロセスを確認する。常駐プロセスが起動時の cwd を保持することがあるため、未コミット変更がなくても使用中なら削除を保留する。

worktree 作成後の準備

1. 作成コマンドの出力を順に読み、依存導入の成功とスキップ理由を確認する。成功表示がないだけで install を始めず、VM の依存ディレクトリの差し替え失敗なら実行しない。パッケージマネージャーを一意に決められ、既存の許可内で lockfile を変更せず導入できる場合に実行する。リモート由来のブランチでは提示にとどめる。自動導入できない場合は理由と必要なコマンドを示す。ホストでは依存導入を VM への同期より先に行う。
2. 信頼やリンク作成の既存判断を引き継ぐ前に、本体で許可済みの対象と worktree の対象を比較する。mise 設定は内容が同じ場合だけ信頼を引き継ぎ、異なる場合は対象パスと必要な操作を示す。親ディレクトリ全体への trust は、今後置く別ブランチの設定も許可するため、個別設定の同一性確認とは区別する。
3. 検査ツールが読み込む設定の絶対パスを確認する。.git/ 配下から上を探索すると本体の設定を選ぶことがあり、両者が同じ内容では誤探索に気づけない。セッション名から基準パスを照合する処理では、実際に使う処理と同じ正規化を候補に施してから符号化する。異なるパスが同じ名前になる場合、worktree 内の深い cwd、名前が不一致の場合も確認し、名前から元のパスを復元できるとは仮定しない。

ブランチ・worktree を削除する前

1. 対象の先端 SHA と取り込み先を明示し、git worktree list で checkout 先と detached HEAD を確認する。PR が merged でも、手元に追加コミットがあることがある。PR の head とローカルの先端も照合する。
2. git status --short --untracked-files=all と git ls-files --others --ignored --exclude-standard で、未コミット・未追跡・無視ファイルを調べる。「取り込み済み」と「消して失うものがない」は別の判定である。.tmp/ の計画・メモや、そのブランチにしかない管理元ファイルを残したまま削除しない。作成直後のブランチも祖先判定では取り込み済みになるため、ファイル確認は省けない。
3. git merge-base --is-ancestor <branch> <target> で履歴に同じコミットがあるか調べる。終了コード 0 は祖先、1 は祖先でないことを示す。それ以外はエラーとして扱い、! command で未取り込みと混同しない。
4. 祖先でなければ git cherry <target> <branch> で差分の同等性を調べる。- は同等のパッチ、+ は未対応のパッチであり、単に squash・rebase の方法を識別する表示ではない。複数コミットの squash は1対1で比べられず、途中の merge や周辺行の変更で patch-id が一致しないこともある。+ だけで内容が欠けていると断定しない。
5. 判定が食い違う場合は git range-diff などで対応するコミットを調べ、変更した全ファイルの内容を取り込み先の対応コミットと照合する。取り込み後に同じ箇所が変わると、現在の target との差分や3-way merge だけでは判定できない。git cherry に -U0 を足しても比較は変わらず、独自に文脈を除く patch-id 比較では位置の違う同じ行も同一視し得る。判定不能なら削除を保留する。
6. git branch -d の拒否は、指定した target への未取り込みを意味するとは限らない。判定先は upstream、なければ現在の HEAD である。-D の前には上記の照合に加え、文書のコミット参照と、元の SHA が取り込み先の履歴に残るかも確認する。内容が同じでも hash 参照を保てるとは限らない。
7. 対象を checkout した worktree を外してからブランチを削除する。detached HEAD は残すブランチがないため、先端コミットの保存先を確認する。cleanup が残存ファイルや対話確認で保留した対象を、まとめて強制削除しない。stash はリポジトリ全体で共有されるので、対象ブランチの後片付けとして削除しない。

リモートとの比較と作業ツリーの更新

1. 比較前に git fetch <remote> を実行する。origin/* は最後の fetch 時点の情報である。git rev-list --left-right --count <local>...<remote>/<branch> の左はローカル固有、右はリモート固有のコミット数として読み、固有コミットの内容も確認する。
2. 更新前に未コミットのファイルと、git diff --stat HEAD..<incoming> などで流入する変更を比較する。重ならなければ未コミット変更があっても fast-forward できる場合がある。重なるときは変更をどう保つか決めてから更新し、自動の退避で他の作業を動かさない。
3. ローカルの --ff-only 成功と push の可否を分けて報告する。ローカル同士が fast-forward できてもリモートとは分岐していることがある。取り込み方はリポジトリの方針を確認する。
4. リモートの base から切った作業ブランチは、upstream が base のままのことがある。初回 push は git push -u <remote> <branch> で作業ブランチ自身を設定し、git branch -vv で確認する。引数なし push が base に向かわないようにする。