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

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

auto gc は次のように手動で実行できます。

繰り返しになりますが、これは通常何も行いません。Gitが実際に gc コマンドを起動するには、約7,000個以上のルーズオブジェクトまたは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が変更されるたびに、その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はありません。この時点で、そのコミットをどのように回復できますか？1つの方法は、データベースの整合性をチェックする git fsck ユーティリティを使用することです。 --full オプションを付けて実行すると、他のオブジェクトから指されていないすべてのオブジェクトが表示されます。

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

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

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

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

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

おっと、プロジェクトに巨大なtarballを追加するつもりはありませんでしたね。さっさと削除しましょう。

さあ、データベースを gc して、どれだけのスペースを使用しているか見てみましょう。

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

size-pack エントリはパックファイルのサイズをキロバイトで表すので、ほぼ5MBを使用しています。最後のコミットの前は2K程度だったので、前のコミットからファイルを削除しても、履歴から削除されたわけではないことが明らかです。誰かがこのリポジトリをクローンするたびに、この小さなプロジェクトを取得するためだけに、誤って大きなファイルを追加したため、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の下に追加した新しいrefsセットにはまだ含まれています。そのため、それらを削除してからデータベースを再パックする必要があります。再パックする前に、それらの古いコミットへのポインタを持つものをすべて削除する必要があります。

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

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