10.7 Gitの内側 - メンテナンスとデータ復旧

Gitは時々「auto gc」というコマンドを自動的に実行します。ほとんどの場合、このコマンドは何もしません。しかし、loose object（packfileにないオブジェクト）が多すぎる場合や、packfileが多すぎる場合、Gitは本格的なgit gcコマンドを起動します。「gc」はガベージコレクションの略で、このコマンドはいくつかのことを行います。すべてのloose objectを収集してpackfileに入れ、複数のpackfileを1つの大きなpackfileに統合し、どのコミットからも到達できず、数ヶ月経過したオブジェクトを削除します。

auto gcを手動で実行することもできます。

繰り返しになりますが、これは通常何も行いません。Gitが実際にgcコマンドを起動するには、約7,000個以上のloose object、または50個以上のpackfileがある必要があります。これらの制限は、それぞれgc.autoとgc.autopacklimitのconfig設定で変更できます。

gcが行うもう1つのことは、参照を単一のファイルにまとめることです。たとえば、リポジトリに以下のブランチとタグが含まれているとします。

git gcを実行すると、refsディレクトリにこれらのファイルはなくなります。Gitは効率のためにこれらを.git/packed-refsというファイルに移動させます。そのファイルは以下のようになります。

参照を更新しても、Gitはこのファイルを編集せず、代わりにrefs/headsに新しいファイルを書き込みます。特定の参照の適切なSHA-1を取得するために、Gitはrefsディレクトリ内でその参照をチェックし、次にフォールバックとしてpacked-refsファイルをチェックします。したがって、refsディレクトリで参照が見つからない場合、それはpacked-refsファイルにある可能性が高いです。

ファイルの最後の行が^で始まることに注目してください。これは、直前のタグがannotated tagであり、その行がannotated tagが指すコミットであることを意味します。

Gitの利用中に、誤ってコミットを失うことがあるかもしれません。これは通常、作業中のブランチを強制的に削除してしまい、後でそのブランチが必要だったと判明した場合や、ブランチをハードリセットして、そこから何かが必要だったコミットを放棄してしまった場合に起こります。このような事態が発生した場合、どのようにしてコミットを取り戻せるのでしょうか？

ここでは、テストリポジトリのmasterブランチを古いコミットにハードリセットし、その後失われたコミットを復旧する例を示します。まず、この時点でのリポジトリの状態を確認しましょう。

では、masterブランチを中間のコミットに戻します。

事実上、上位2つのコミットを失いました。これらのコミットに到達できるブランチがありません。最新のコミットSHA-1を見つけて、それにポインタを持つブランチを追加する必要があります。問題は、その最新のコミットSHA-1を見つけることです。覚えているわけではありませんよね？

多くの場合、最も手っ取り早い方法はgit reflogというツールを使うことです。作業中、GitはHEADが変更されるたびに、その状態を密かに記録しています。コミットしたりブランチを変更したりするたびに、reflogが更新されます。reflogはgit update-refコマンドによっても更新されます。これは、Git参照で説明したように、単にSHA-1値を参照ファイルに書き込むのではなく、このコマンドを使用するもう1つの理由です。git reflogを実行することで、いつでもどこにいたかを確認できます。

ここではチェックアウトしていた2つのコミットを見ることができますが、あまり多くの情報はありません。同じ情報をより有用な方法で見るには、git log -gを実行できます。これは、reflogの通常のログ出力を提供します。

どうやら一番下のコミットが失われたもののようですので、そのコミットに新しいブランチを作成して復旧できます。たとえば、そのコミット（ab1afef）でrecover-branchという名前のブランチを開始できます。

素晴らしい — これでmasterブランチがあった場所にrecover-branchというブランチが作成され、最初の2つのコミットに再び到達できるようになりました。次に、何らかの理由で失われたコミットがreflogにない場合を想定します。それはrecover-branchを削除し、reflogを削除することでシミュレートできます。これで最初の2つのコミットには何も到達できなくなります。

reflogデータは.git/logs/ディレクトリに保存されているため、実質的にreflogがない状態です。この時点でそのコミットをどうやって復旧できるでしょうか？一つの方法は、データベースの整合性をチェックするgit fsckユーティリティを使用することです。--fullオプションを付けて実行すると、他のオブジェクトから指されていないすべてのオブジェクトが表示されます。

この場合、「dangling commit」という文字列の後に、失われたコミットが表示されています。同様に、そのSHA-1を指すブランチを追加することで復旧できます。

Gitには素晴らしい点がたくさんありますが、問題を引き起こす可能性のある機能の1つは、git cloneがプロジェクトの履歴全体（すべてのファイルのすべてのバージョンを含む）をダウンロードするという事実です。全体がソースコードであれば問題ありません。なぜなら、Gitはそのデータを効率的に圧縮するために高度に最適化されているからです。しかし、プロジェクトの履歴のどこかの時点で誰かが単一の巨大なファイルを追加した場合、たとえそのファイルが直後のコミットでプロジェクトから削除されたとしても、それ以降のすべてのクローンはその大きなファイルをダウンロードすることを強制されます。履歴から到達可能であるため、それは常にそこに存在し続けます。

これは、SubversionやPerforceのリポジトリをGitに変換する際に大きな問題となることがあります。これらのシステムでは履歴全体をダウンロードしないため、この種の追加による影響は少ないです。もし別のシステムからインポートした場合や、リポジトリが本来あるべきよりもはるかに大きいことに気づいた場合、大きなオブジェクトを見つけて削除する方法を以下に示します。

警告：この手法はコミット履歴を破壊します。 これは、大きなファイル参照を削除するために変更する必要がある最も古いツリー以降のすべてのコミットオブジェクトを書き換えます。インポート直後で、まだ誰もそのコミットに基づいて作業を開始していないのであれば問題ありません。そうでない場合は、すべての貢献者に、新しいコミットに作業をリベースする必要があることを通知しなければなりません。

実演するために、テストリポジトリに大きなファイルを追加し、次のコミットで削除し、見つけて、リポジトリから完全に削除します。まず、履歴に大きなオブジェクトを追加します。

しまった — プロジェクトに巨大なtarballを追加したくなかった。削除した方がいいだろう。

次に、データベースをgcして、どれくらいのスペースを使用しているかを確認します。

count-objectsコマンドを実行すると、使用しているスペースの量を素早く確認できます。

size-packエントリはパックファイルのサイズをキロバイト単位で示しており、約5MBを使用しています。最後のコミットの前は2KBに近かったので、前のコミットからファイルを削除しても履歴からは削除されていないことが明らかです。誰かがこのリポジトリをクローンするたびに、誤って大きなファイルを追加したせいで、この小さなプロジェクトを得るためだけに5MBすべてをクローンしなければなりません。これを削除しましょう。

まずそれを見つけなければなりません。このケースでは、どのファイルであるかはすでにわかっています。しかし、わからなかったとしたらどうでしょう？どのファイルがそんなに多くのスペースを占めているかをどうやって特定しますか？git gcを実行すると、すべてのオブジェクトはパックファイルに入ります。大きなオブジェクトを特定するには、git verify-packという別のプラミングコマンドを実行し、出力の3番目のフィールド（ファイルサイズ）でソートします。最後の数個の最も大きなファイルにしか興味がないので、tailコマンドを通してパイプすることもできます。

一番下に大きなオブジェクトがあります：5MB。それが何のファイルかを知るには、特定のコミットメッセージ形式の強制で少し使ったrev-listコマンドを使います。rev-listに--objectsを渡すと、すべてのコミットSHA-1と、それに関連付けられたファイルパスを持つblob SHA-1がリストされます。これを使ってblobの名前を見つけることができます。

次に、過去のすべてのツリーからこのファイルを削除する必要があります。どのコミットがこのファイルを変更したかは簡単に見ることができます。

このファイルをGitの履歴から完全に削除するには、7b30847より下流のすべてのコミットを書き換える必要があります。そのためには、履歴の書き換えで使ったfilter-branchを使います。

--index-filterオプションは、履歴の書き換えで使用した--tree-filterオプションに似ていますが、ディスクにチェックアウトされたファイルを変更するコマンドを渡す代わりに、毎回ステージングエリアまたはインデックスを変更するという点が異なります。

rm fileのようなもので特定のファイルを削除するのではなく、git rm --cachedで削除する必要があります。つまり、ディスクからではなくインデックスから削除しなければなりません。この方法で行う理由は速度です。Gitはフィルターを実行する前に各リビジョンをディスクにチェックアウトする必要がないため、プロセスが非常に速くなります。必要であれば--tree-filterで同じタスクを達成することもできます。git rmの--ignore-unmatchオプションは、削除しようとしているパターンが存在しない場合にエラーを出さないように指示します。最後に、filter-branchに7b30847コミット以降の履歴のみを書き換えるように依頼します。なぜなら、問題がそこで始まったことを知っているからです。そうしないと、最初から始まり、不必要に時間がかかります。

これで履歴にはそのファイルへの参照は含まれなくなりました。しかし、reflogと、filter-branchを実行した際にGitが.git/refs/original以下に追加した新しい参照群にはまだその参照が残っているので、それらを削除し、その後データベースを再パックする必要があります。再パックする前に、古いコミットへのポインタを持つものをすべて削除する必要があります。

どれくらいのスペースを節約できたか見てみましょう。

パックされたリポジトリのサイズは8KBに減少し、5MBよりもはるかに良くなりました。サイズ値から、大きなオブジェクトがまだloose objectに残っていることがわかります。つまり、完全には削除されていません。しかし、プッシュやその後のクローンでは転送されません。これが重要な点です。もし本当に完全に削除したいのであれば、git prune --expireオプションを実行することでオブジェクトを完全に削除できます。