10.7 Gitの内側 - メンテナンスとデータリカバリ

Gitは時々 “auto gc” と呼ばれるコマンドを自動的に実行します。 大抵の場合、このコマンドは何もしません。 ですが、緩いオブジェクト（packfileの中に入っていないオブジェクト）やpackfileがあまりに多い場合は、Gitは完全な（full-fledged）git gc コマンドを起動します。 “gc” はガベージコレクト（garbage collect）を意味します。このコマンドは幾つものことを行います。すべての緩いオブジェクトを集めてpackfileに入れ、複数のpackfileをひとつの大きなpackfileに統合し、さらにどのコミットからも到達が不可能かつ数ヶ月間更新がないオブジェクトを削除します。

次のように手動でauto gcを実行することもできます。

繰り返しますが、これは通常は何も行いません。 約7,000個もの緩いオブジェクトがあるか、または50以上のpackfileがある場合でないと、Gitは実際にgcコマンドを開始しません。 これらのリミットはそれぞれ設定ファイルの gc.auto と gc.autopacklimit で変更できます。

その他に gc が行うこととしては、複数の参照を1つのファイルにパックすることが挙げられます。 リポジトリに、次のようなブランチとタグが含まれているとしましょう。

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

ただ、ここで参照を更新しても、Gitはこのファイルを編集せず、その代わりに refs/heads に新しいファイルを書き込みます。 とある参照に対する適切なSHA-1ハッシュを得るために、Gitは refs ディレクトリ内でその参照をチェックした上で、見つからなかった場合の代替として packed-refs ファイルをチェックします。 一方、 refs ディレクトリ内で参照が見つけられない場合は、それはおそらく packed-refs ファイル内にあります。

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

Gitを使っていく過程のある時点で、誤ってコミットを失ってしまうことがあるかもしれません。 このようなことが起こりがちなのは、成果物が入っていたブランチをforce-deleteしたけれど、その後結局そのブランチが必要になったときか、あるいはブランチをhard-resetしたために、何か必要なものが入っているコミットがそのブランチから切り離されてしまったときです。 このようなことが起きたとして、どうやったらコミットを取り戻せるでしょうか？

以下に示す例では、testリポジトリ内のmasterブランチを古いコミットにhard-resetして、それから失ったコミットを復元します。 まず、今の時点でリポジトリがどのような状況にあるのか調べてみましょう。

ここで、master ブランチを真ん中のコミットの時点まで戻します。

これで、一番上にあった2つのコミットは、事実上失われたことになります。これらのコミットに辿り着けるブランチがないためです。 そのため、最後のコミットのSHA-1ハッシュを調べた上で、そこを指すブランチを追加する必要があります。 ここでポイントとなるのは、最後のコミットのSHA-1ハッシュを見つける方法です。ハッシュ値を記憶してます、なんてことはないですよね？

大抵の場合、最も手っ取り早いのは、git reflog というツールを使う方法です。 あなたが作業をしている間、HEADを変更する度に、HEADがどこを指しているかをGitは裏で記録しています。 コミットをしたり、ブランチを変更したりする度に、reflogは更新されます。 また、reflogは git update-ref コマンドによっても更新されます。refファイルに書かれたSHA-1ハッシュ値を直に編集せずに、このコマンドを使って編集すべき理由の1つがこれです（詳しくは Gitの参照 で取り上げました）。 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には素晴らしい点がたくさんありますが、問題となり得る特徴がひとつあります。それは、 git clone がすべてのファイルのすべてのバージョンを含んだプロジェクトの歴史全体をダウンロードしてしまうということです。 保存されているのがソースコードだけなら、特に問題はありません。なぜなら、Gitはそのようなデータを効率良く圧縮することに高度に最適化されているからです。 しかし、もし誰かがある時点でプロジェクトの歴史に非常に大きなファイルを1つ加えると、以降のクローンではすべて、その大きなファイルのダウンロードを強いられることになります。これは、直後のコミットでそのファイルをプロジェクトから削除したとしても変わりません。 なぜなら、そのファイルは履歴から到達可能であり、常にそこに存在し続けるためです。

SubversionやPerforceのリポジトリをGitに変換するときに、これは大きな問題になり得ます。 なぜなら、それらのシステムではすべての履歴をダウンロードする必要がないため、非常に大きなファイルを追加してもほとんど悪影響がないからです。 別のシステムからリポジトリをインポートした場合や、リポジトリがあるべき状態よりもずっと大きくなっている場合に、大きなオブジェクトを見つけて取り除く方法を以下に示します。

注意: この操作はコミット履歴を破壊的に変更します。 この操作では、大きなファイルへの参照を取り除くため、修正が必要な一番古いツリーから、以降すべてのコミットオブジェクトを再書き込みします。 インポートの直後、そのコミットをベースとして誰かが作業を始める前にこの操作を行った場合は問題ありません。そうでない場合は、作業中の内容を新しいコミットにリベースしなければならないことを、すべての関係者に知らせる必要があります。

実演のため、testリポジトリに大きなファイルを追加して、次のコミットでそれを取り除いた上で、リポジトリからそのファイルを探し出し、そしてリポジトリからそれを完全に削除します。 まず、あなたの歴史に大きなオブジェクトを追加します。

おっと、誤ってプロジェクトに非常に大きなtarボールを追加してしまいました。取り除いたほうがいいでしょう。

次に、データベースに対して gc を実行します。その後、どれくらいのスペースを使用しているのかを見てみましょう。

count-objects コマンドを実行すると、どれくらいのスペースを使用しているのかをすぐに見ることができます。

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

最初に、その大きなファイルを見つけなければなりません。 この例では、どのファイルがそれかは既に分かっています。 しかし、それが分からない場合、どうやって多くのスペースを占めているファイルを特定するのでしょうか？ git gc を実行すると、すべてのオブジェクトがpackfileに格納されます。 そのため、別の配管コマンド git verify-pack を実行し、その出力を3つ目のフィールド（ファイルサイズ）でソートすれば、大きなオブジェクトを特定できます。 関心の対象になるのは最も大きなファイル数個だけなので、その出力をパイプで tail コマンドに通してもよいでしょう。

探していた大きなオブジェクトは、一番下の5MBのものです。 そのオブジェクトが何のファイルなのかを知るには 特定のコミットメッセージ書式の強制 で少し使用した rev-list コマンドを使用します。 --objects を rev-list に渡すと、すべてのコミットのSHA-1ハッシュに加えて、すべてのブロブのSHA-1ハッシュと、そのブロブに関連付けられたファイルのパスを一覧表示します。 これは、ブロブの名前を特定するのに使えます。

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

Gitリポジトリからこのファイルを完全に削除するには、 7b30847 の下流にあるすべてのコミットを修正しなければなりません。 そのためには、 歴史の書き換え で使用した filter-branch を使用します。

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

ここでは、あるファイルを rm file で削除するのではなく、 git rm --cached で削除する必要があります。つまり、ディスクではなくインデックスからファイルを削除しなければなりません。 このようにする理由はスピードです。この場合、Gitがフィルタを実行する前に各リビジョンをディスク上へチェックアウトする必要がないので、プロセスをもっともっと速くすることができます。 お望みなら、同様のタスクは --tree-filter でも行えます。 git rm に渡している --ignore-unmatch オプションは、削除しようとするパターンに合うファイルがない場合に、エラーを出力しないようにします。 最後に、filter-branch に、コミット 7b30847 以降の履歴のみを修正するように伝えています。なぜなら、問題が発生した場所がここだと分かっているからです。 そうでない場合は、歴史の先頭から処理を開始することになり、不必要に長い時間がかかるでしょう。

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

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

パックされたリポジトリのサイズは8KBに下がり、当初の5MBよりもずっとよくなりました。 サイズの値を見ると、緩いオブジェクトの中には大きなオブジェクトが残っており、無くなったわけではないことが分かります。ですが、プッシュや以降のクローンで転送されることはもうありません。ここが重要な点です。 お望みなら、 git prune に --expire オプションを指定すれば、オブジェクトを完全に削除することもできます。