テクノロジー · 実用ガイド
Git の「cannot lock ref」？削除前にエラー末尾を分類する
「is at… but expected」「exists; cannot create」「unable to resolve」は別の障害です。正確な ref と OID を保存し、競合する書き手を止め、証明できた分岐だけを修復します。
「Cannot lock ref」はエラーの接頭辞であり、単一の診断ではありません。残りの文が、expected old OID の競合、階層名の衝突、壊れた ref、または lock 作成失敗を示します。
何かを削除する前に完全な行と現在の ref 値を保存します。background fetcher や CI writer を止め、末尾を分類し、新しい作業を残す狭い修復だけを行います。
正確な ref、末尾、OID を保存
完全なエラー、command、repository path と「remote:」の有無を保存します。git rev-parse --git-common-dir、git version、git status --short --branch、完全な ref 名も記録します。
完全な ref に git show-ref --verify を使い、git for-each-ref で周辺名前空間を確認します。変更前に現在 OID と remote 値を保存します。
「is at A but expected B」を競合として扱う
これは compare-and-swap 保護です。Git は B を期待し A を再読しました。background fetch、IDE integration、重複 CI を止め、A が有効な更新か確認します。
A が有効なら fresh fetch または push を一度だけ再実行します。B を強制的に戻したり ref を削除したりすると新しい作業を失います。
名前空間と大小文字衝突を意図的に解決
「X exists; cannot create X/Y」では local と remote の完全な refs を一覧します。file-based storage では foo が foo/bar を妨げます。owner と名称を決め、OID を保存してから変更します。
Windows などでは case-insensitive な比較も行います。clean clone は衝突確認に使えますが、remote branch の無断 rename はできません。
active lock と broken ref を分ける
「unable to resolve reference」では Git command で ref を調べます。packed、loose、symbolic、reftable の可能性があります。git fsck --full を実行し packed-refs を手編集しません。
.lock がある場合は Git process、hook、IDE、backup、server task が所有していないことを証明します。停止済み操作の orphan lock だけが stale-lock 分岐です。
狭い修復を検証して原因を閉じる
local ref 修正が必要なら expected old OID 付き git update-ref を優先します。namespace 衝突は合意した rename/delete 後に fetch、race は fresh retry 一回です。
git show-ref、git fsck --full、一回の fetch または push と remote OID 比較で終了し、並行 writer、階層名、case folding、中断 lock、権限、broken ref の原因を記録します。
