Gitの深淵を覗く：`git-fsck`による壊死リポジトリの外科手術と、その「死」を許さない自動化戦略
Gitは「分散型」であるという性質上、我々はしばしばその堅牢さを過信している。しかし、ディスクのビット腐敗（Bit Rot）、予期せぬ電源断、あるいは不適切な`.git`ディレクトリへの直接操作は、確実にリポジトリの心臓部を蝕む。
`fatal: loose object … is corrupt` というエラーを吐かれ、CI/CDパイプラインが停止した瞬間、多くのエンジニアは「`git clone`し直せ」という安易な結論に飛びつく。だが、それが数テラバイトの巨大リポジトリや、ローカルにしか存在しない無数のWIPコミットを抱えた環境だったらどうする？
今日は、Gitの内部構造（Object Database）を直接操作し、死にゆくリポジトリを蘇生させる「外科手術」と、それをインフラレベルで封じ込める知見を共有する。
—
1. `git-fsck`：静かなる検死官の真の使い道
`git-fsck`は単なるチェックツールではない。Gitの有向非巡回グラフ（DAG）の整合性を検証する唯一の「真実の鏡」だ。
単に `git fsck –full` を打つだけでは素人だ。プロは以下のフラグを駆使して、破損の範囲を特定する。
オブジェクトの整合性チェックに加え、到達不能なオブジェクトを列挙する
–strict を付けることで、不正なファイルモードや、
不適切な日付形式などの「緩い破損」も厳格に叩き出す
git fsck –full –strict –verbose
破損の兆候を見逃すな
特に注意すべきは `dangling commit` ではない。`missing blob` や `checksum mismatch` が出た時が、本当の戦いの始まりだ。Gitは「内容のハッシュ値」をキーとしてデータを管理しているため、一度でもハッシュが食い違えば、そのデータは事実上の「死」を意味する。
—
2. 壊れたオブジェクトを外科的に摘出・修復する
もし、破損したオブジェクトが特定できた場合、以下の手順で「蘇生」を試みる。
ステップA：破損オブジェクトの特定
`git-fsck`の出力からハッシュ値を取得する。例えば `e69de2…` が壊れているとする。
ステップB：手動復旧の限界と真実
ここで重要なのは、「破損したオブジェクトそのものを修復する魔法はない」という事実だ。できることは以下の3つのみ。
1. リモートからの再取得: `git fetch`で該当オブジェクトを再ダウンロード（これが最も健全）。
2. Packfileの再構築: `git gc –prune=now` で破損ファイルを一度除去し、完全なバックアップから再送出する。
3. オブジェクトの再生成: 壊れたのが「ソースコードの断片」なら、過去のステートから復元したファイルを再度 `git hash-object -w` でデータベースに突っ込む。
破損したオブジェクトを特定した後の強硬手段
壊れたオブジェクトを無理やり削除し、リモートから再取得を促す
rm .git/objects/e6/9de2…
その後、オブジェクトを再構成する
git fetch –all
git fsck –full
—
3. 「死なない」CI/CDパイプラインの構築：プロのハック
リポジトリが壊れてから直すのは、下策中の下策である。我々DevOpsエンジニアがやるべきは、「破損を早期検出し、即座に隔離する自動化」だ。
独自のヘルスチェック・サイドカー
大規模なCI/CDパイプラインでは、ジョブの開始前に必ず `git-fsck` を実行するスクリプトを差し込む。これは `pre-build` フェーズの定石だ。
!/bin/bash
.ci/health_check.sh
パイプライン内でリポジトリの健全性を保証するスクリプト
set -e
メモリ消費を抑えるため、大規模リポジトリでは –no-reflogs を活用
整合性チェックを並列化させる
if ! git fsck –full –strict –no-reflogs –progress; then
echo “CRITICAL: Repository corruption detected!”
# 破損を検知した場合、Slack/Teamsへ即時通知し、ビルドを停止させる
curl -X POST -H ‘Content-type: application/json’ –data ‘{“text”:”Git Corruption Detected on Agent: ‘$HOSTNAME'”}’ $WEBHOOK_URL
exit 1
fi
パフォーマンス最適化ハック：メモリとI/Oの制御
数百万コミットを超えるリポジトリで `git-fsck` を走らせると、メモリを食いつぶし、ディスクI/Oを飽和させる。この時、`git`の内部設定でメモリを制限することが肝要だ。
git-fsck実行時に使用する一時メモリを制限
git -c core.bigFileThreshold=100m fsck –full
—
4. 伝説的アーキテクトからの提言：バージョン管理の「設計」
リポジトリが頻繁に破損する組織は、Gitの使い方が間違っている。
1. Submoduleの過度な利用を避ける: 複雑な依存関係は、CIパイプライン上での破損リスクを指数関数的に増大させる。
2. 巨大バイナリはGit LFSへ: `git-fsck` はLFSオブジェクトを追わない。LFSサーバー側で整合性チェックを行い、Gitサーバー（Object Store）と分離せよ。
3. ディスクストレージの選定: 仮想環境において、安易な `overlayfs` やネットワークストレージ（NFS）は、Gitのロック機構を破壊し、破損の温床となる。ブロックストレージ（EBS等）の使用は絶対条件だ。
結論
Gitが壊れた時、それはリポジトリの死ではない。「管理体制の死」だ。`git-fsck` は、あなたの管理能力を試すリトマス試験紙に過ぎない。
今日から、すべてのビルドパイプラインに `fsck` を組み込め。壊れることを前提にシステムを組み、壊れた瞬間に検知し、即座にクリーンな環境へ切り替える。それこそが、DevOpsの最前線に立つ者に求められる「真のレジリエンス」である。
君のリポジトリは、今この瞬間も健全か？ 確認するなら、今すぐCLIを叩け。