やあ。Gitを使い始めてしばらく経つと、ふと「なぜかリポジトリが重い」「`git gc`をしてもサイズが減らない」という壁にぶつかるはずだ。
それは君が優秀なエンジニアとして、多くの試行錯誤を繰り返してきた証拠でもある。しかし、その「試行錯誤の残骸」がリポジトリを肥大化させ、パフォーマンスを低下させているとしたらどうだろう？
今日は、Gitの深層心理――「ゴミの定義」を理解し、安全かつ確実にリポジトリを断捨離する術を伝授する。これをマスターすれば、君のリポジトリは常に軽量で、爆速な状態を維持できるようになる。準備はいいかい？
—
1. なぜリポジトリは肥大化するのか？（Gitの「不気味な」仕様）
Gitは非常に賢い。君がコミットを削除したり、ブランチを消したりしても、Gitは「もし後で必要になったらどうする？」と気を利かせて、裏でデータを保持し続ける。
- 孤立オブジェクト（Dangling Objects）: どのブランチからも参照されていないが、Gitの内部データベースには残っているコミットやファイルのこと。
- なぜ消えないのか: Gitは「安全第一」の設計思想を持っている。参照がなくなっただけで即座に削除すると、誤って消した時に復旧できなくなるからだ。
この「親切心」が積もり積もると、リポジトリは巨大なゴミ屋敷と化す。今日はこれを、適切な手順で掃除する。
—
2. 「ゴミ」を特定する：`git fsck`の魔力
まずは、今君のリポジトリ内にどれだけの「孤立オブジェクト」があるかを確認しよう。ターミナルを開いて、対象のリポジトリ内で以下を叩いてみてほしい。
孤立したオブジェクト（参照されていないコミットやファイル）を列挙する
git fsck –full –no-reflogs –unreachable
ずらりと表示されただろう？ これらが、今の君のプロジェクトを重くしている犯人たちだ。
—
3. 歴史を書き換える前に：`reflog`という「安全装置」
Gitには、ユーザーの操作ミスを救うための「タイムマシン」が存在する。それが `reflog` だ。
過去のあらゆる操作履歴を表示
git reflog
このリストに載っている限り、Gitは「まだ必要かもしれない」と判断し、オブジェクトを削除から保護する。つまり、本気で断捨離するためには、この「タイムマシンの記録」さえも期限切れにする必要があるのだ。
—
4. ステップバイステップ：完全駆除の極意
それでは、安全かつ確実にリポジトリを軽量化する手順を説明する。
手順①：reflogの期限を強制的に切る
まずは、古い記録を「もう不要」とマークしよう。
現在から数えて「期限切れ」とみなす期間を0に設定し、過去の記録を全て抹消対象にする
git reflog expire –expire=now –all
手順②：孤立オブジェクトをパージする
記録が消えた今、Gitは「これらは本当に不要だ」と判断できるようになる。
孤立したオブジェクトを完全に駆除する
git gc –prune=now –aggressive
- `–prune=now`: 期限切れのオブジェクトを即座に削除。
- `–aggressive`: オブジェクトを再パックし、最大限まで圧縮する。
—
5. 動作確認：軽量化の成果を実感する
どれくらい軽くなったかを確認する最も確実な方法は、`.git` ディレクトリのサイズを見ることだ。
リポジトリのサイズを確認
du -sh .git
どうだい？ 驚くほど小さくなったはずだ。もし大規模なプロジェクトであれば、数十MB〜数百MB単位で削減できることもある。
—
最後に：先輩からのアドバイス
この手順は非常に強力だが、「一度実行すると、過去の誤操作を取り消せなくなる」というリスクがある。だからこそ、以下の鉄則を守ってほしい。
1. バックアップをとれ: 大事なリポジトリなら、まずコピーを作ってから実行する。
2. チーム共有リポジトリでは慎重に: 共有サーバー上のリポジトリにこれを適用する場合は、必ずチームメンバーに事前通達すること。
Gitを使いこなすということは、コマンドを覚えることではなく、「Gitが何を考え、どう動いているか」を理解することだ。
リポジトリを綺麗に保つことは、コードを綺麗に保つことと同じくらい重要だよ。これができれば、君の毎日の開発はもっと軽快で、ストレスのないものになるはずだ。
また何か困ったことがあればいつでも聞いてくれ。応援しているよ。