Gitの「死」に立ち会う君へ。`git-fsck` でリポジトリの心拍を蘇生させる技術
エンジニアとして長くコードを書いていると、一度は経験するだろう。`fatal: loose object … is corrupt` という絶望的なエラー。ディスクの物理故障、不完全なプッシュ、あるいは誰かが `.git` ディレクトリを不用意にいじった結果……。
リポジトリはチームの「信頼の源泉（Source of Truth）」だ。これが壊れた時、慌ててクローンし直すのは二流のやることだ。一流は、その臓器を解剖し、手動で縫合する術を知っている。今日は、Gitの深淵を覗くコマンド `git-fsck` と、その修復術について語ろう。
—
1. 診断：`git-fsck` が告げる「死因」
リポジトリが怪しいと感じたら、まずは `git-fsck –full` を実行せよ。これがGitの健康診断だ。
–full: 全ての参照とオブジェクトを走査
–strict: より厳格にチェック（推奨）
git fsck –full –strict
出力結果には主に2種類ある。
- dangling commit/blob: 「迷子」のオブジェクト。ゴミ掃除（`git gc`）で消える運命にあるが、時には「消えてはいけないもの」がここにある。
- corrupt/missing object: 致命傷。ハッシュ値が指し示す実体が見当たらない、または中身が壊れている。
2. 修復：ハッシュの彼方へ
壊れたオブジェクトが特定できたら（例: `dangling blob
中身の型を確認
git cat-file -t
中身をダンプ（破損しているとここでエラーが出る）
git cat-file -p
【プロの知見：修復の限界】
ここが現実だ。もしそのオブジェクトが `blob` （ファイルの中身）で、かつリモート（GitHub/GitLab）に無事なコピーがあるなら、`git fetch` で再取得できる。しかし、ローカルでしか存在しないコミットデータが完全に破損した場合、そのコミット履歴を再構築することは理論上不可能に近い。
その場合、私は以下の「外科手術」を推奨する。
1. 壊れたコミットの親を探す: `git log –graph` で破損地点の直前を特定。
2. リセット: 破損したコミットを `git reset –hard <親のハッシュ>` で切り離す。
3. 再コミット: ワークツリーに残った差分を再び `git add` し、新しいハッシュで履歴を繋ぎ直す。
—
3. 生産性を加速させる「極限のGit環境」
リポジトリを壊さないための運用、そして爆速で開発するための設定を伝授しよう。これを入れるだけで、君のチームの生産性は確実に20%底上げされる。
A. 絶対入れるべき神プラグイン：`git-delta`
`git diff` が見づらい？ `diff-so-fancy` もいいが、今は `delta` 一択だ。シンタックスハイライト、行の強調表示、サイドバイサイド表示が最強。
.gitconfig への設定例
[core]
pager = delta
[delta]
navigate = true # n/N でファイル間を移動可能にする
light = false # ダークモード用
side-by-side = true
B. チーム開発の「設定共有化」ルール
`git config –global` は個人の自由だが、プロジェクト単位の設定はリポジトリのルートに `.gitconfig` ではなく `.git/config` の内容をテンプレートとして `.gitconfig.local` に含める文化を作れ。
また、`husky` を使ったプリコミットフックの自動インストールは必須だ。
// package.json (Node.js環境の例)
{
“husky”: {
“hooks”: {
“pre-commit”: “lint-staged”,
“pre-push”: “git fsck –full –strict” // プッシュ前に健全性をチェック！
}
}
}
C. 隠れたキーボードショートカット
`git` はCLIで完結させるのが一流だが、以下のエイリアスは体に叩き込んでおけ。
頻繁に使う履歴の可視化を爆速にする
alias gl=’git log –graph –pretty=format:”%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset” –abbrev-commit’
壊れたリポジトリの修復・整理用（Gitガベージコレクションの最適化）
alias gc-fast=’git gc –aggressive –prune=now’
—
4. 最後に：テックリードからの提言
Gitはただのバージョン管理ツールではない。君のチームの「思考の記録」だ。
`git-fsck` で壊れたリポジトリを直す作業は、単なるトラブルシューティングではない。それは、Gitの内部構造（Object Database）を理解する最高のトレーニングになる。
もし、この記事を読んでいる君の隣で誰かが「`fatal: …`」と呟いていたら、慌てて `rm -rf` を勧めるのではなく、まず `git fsck` を教えろ。それが、技術力をチーム全体で底上げするということだ。
リポジトリを慈しみ、CLIの深淵を愛せ。それが、最高峰のDevOpsエンジニアへの道だ。