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

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

次のようにして、auto gcを手動で実行できます。

繰り返しますが、これは一般的には何も行いません。Gitが実際のgcコマンドを起動するには、約7,000個以上のlooseオブジェクト、または50個以上のパックファイルが必要です。これらの制限は、それぞれgc.autoおよびgc.autopacklimitの設定で変更できます。

gcが行うもう1つのことは、参照を1つのファイルにパックすることです。リポジトリに次のブランチとタグが含まれているとします。

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

参照を更新すると、Gitはこのファイルを編集する代わりに、新しいファイルをrefs/headsに書き込みます。指定された参照に適切なSHA-1を取得するために、Gitはrefsディレクトリでその参照を確認し、フォールバックとしてpacked-refsファイルを確認します。したがって、refsディレクトリに参照が見つからない場合は、おそらくpacked-refsファイルにあります。

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

Gitの旅の途中で、誤ってコミットを失ってしまうことがあるかもしれません。一般的に、これは作業内容のあるブランチを強制的に削除してしまい、やはりそのブランチが必要になった場合や、ハードリセットでブランチを過去に戻し、そこから何かを取得したかったコミットを破棄した場合に起こります。このような事態が発生した場合、どのようにコミットを取り戻すことができるでしょうか？

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

次に、masterブランチを中央のコミットに戻します。

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

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

ここではチェックアウトした2つのコミットを確認できますが、あまり情報がありません。同じ情報をより有益な形で確認するには、git log -gを実行します。これはreflogの通常のログ出力を表示します。

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

これで、recover-branchという名前のブランチが、以前のmasterブランチと同じ位置に作成され、最初の2つのコミットに再び到達できるようになりました。次に、何らかの理由でreflogに記録されていない場合を考えます。recover-branchを削除し、reflogを削除することで、それをシミュレートできます。これで、最初の2つのコミットにはどこからも到達できなくなります。

reflogのデータは.git/logs/ディレクトリに保存されているため、reflogは事実上存在しません。この時点で、どのようにコミットを復元できるでしょうか？1つの方法は、データベースの整合性をチェックするgit fsckユーティリティを使用することです。--fullオプションを指定して実行すると、別のオブジェクトから参照されていないすべてのオブジェクトが表示されます。

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

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

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

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

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

おっと、プロジェクトに巨大なtarballを追加したくなかったようです。削除しましょう。

次に、データベースをgcして、使用しているスペースの量を確認します。

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

size-packエントリは、パックファイルのサイズ（キロバイト単位）であり、ほぼ5MBを使用していることがわかります。最後のコミットの前は、2K近くでした。つまり、前のコミットからファイルを削除しても、履歴からは削除されませんでした。このリポジトリをクローンするたびに、誤って大きなファイルを追加してしまったため、この小さなプロジェクトのために5MBをクローンする必要があります。削除しましょう。

まず、それを見つける必要があります。この場合は、どのファイルかはすでにわかっています。しかし、わからなかった場合はどうでしょうか。どのファイルがそんなに容量を消費しているかをどのように特定できるでしょうか？git gcを実行すると、すべてのオブジェクトがパックファイルに格納されます。git verify-packという別の配管コマンドを実行し、出力の3番目のフィールドであるファイルサイズでソートすることで、大きなオブジェクトを特定できます。また、最後の数個の最大のファイルのみに関心があるので、tailコマンドにパイプすることもできます。

一番下にあるのが大きなオブジェクト（5MB）です。それがどのファイルかを知るには、特定のコミットメッセージ形式の強制で簡単に使用したrev-listコマンドを使用します。--objectsをrev-listに渡すと、すべてのコミット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の下に追加した新しい参照セットには、まだ含まれているため、それらを削除してからデータベースを再パックする必要があります。再パックする前に、古いコミットへのポインターを持つものをすべて削除する必要があります。

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

パックされたリポジトリのサイズは8Kまで小さくなり、5MBよりもはるかに優れています。サイズの値から、大きなオブジェクトがまだlooseオブジェクトにあることがわかります。したがって、消えたわけではありませんが、プッシュや後続のクローンでは転送されません。これが重要なことです。どうしてもオブジェクトを完全に削除したい場合は、--expireオプションを指定してgit pruneを実行できます。