English ▾ トピック ▾ 最新バージョン ▾ git-gc は 2.49.0 で最終更新されました

名前

git-gc - 不要なファイルのクリーンアップとローカルリポジトリの最適化

概要

git gc [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]

説明

現在のリポジトリ内で、ファイルリビジョンの圧縮（ディスク容量の削減とパフォーマンスの向上）、以前の git add の呼び出しから作成された可能性のある到達不能なオブジェクトの削除、参照のパッキング、reflog、rerere メタデータ、または古い作業ツリーのプルーニングなど、さまざまなハウスキーピングタスクを実行します。コミットグラフなどの補助的なインデックスを更新することもできます。

オブジェクトを作成する一般的なポーセリン操作が実行されると、最後にメンテナンスされてからリポジトリが大幅に増加したかどうかを確認し、増加していれば git gc を自動的に実行します。この動作を無効にする方法については、以下の gc.auto を参照してください。

git gc を手動で実行する必要があるのは、定期的にそのようなポーセリンコマンドを実行せずにリポジトリにオブジェクトを追加する場合、一回限りのリポジトリ最適化を行う場合、または例えば最適な状態ではない大量インポートをクリーンアップする場合などです。インポートのケースの詳細については、git-fast-import[1] の「PACKFILE OPTIMIZATION」セクションを参照してください。

オプション

--aggressive

通常、git gc は非常に高速に実行され、良好なディスク容量利用率とパフォーマンスを提供します。このオプションを使用すると、git gc ははるかに多くの時間を要する代わりに、リポジトリをより積極的に最適化します。この最適化の効果はほとんど永続的です。詳細については、以下の「AGGRESSIVE」セクションを参照してください。

--auto

このオプションを使用すると、git gc はハウスキーピングが必要かどうかをチェックします。不要であれば、何も実行せずに終了します。

このヒューリスティックがどのように機能するかについては、以下の「CONFIGURATION」セクションの gc.auto オプションを参照してください。

gc.auto や gc.autoPackLimit などの設定オプションの制限を超えてハウスキーピングがトリガーされると、他のすべてのハウスキーピングタスク（例: rerere、作業ツリー、reflogなど）も実行されます。

--[no-]detach

システムがサポートしていればバックグラウンドで実行します。このオプションは gc.autoDetach 設定を上書きします。

--[no-]cruft

到達不能なオブジェクトを期限切れにする際、それらをルーズオブジェクトとして保存する代わりに、個別のクラフトパックにパックします。--cruft はデフォルトでオンです。

--max-cruft-size=<n>

到達不能なオブジェクトをクラフトパックにパックする際、新しいクラフトパックのサイズを最大 <n> バイトに制限します。gc.maxCruftSize 設定で指定された値をすべて上書きします。git-repack[1] の --max-cruft-size オプションをさらに参照してください。

--expire-to=<dir>

到達不能なオブジェクトをクラフトパックにパックする際、プルーニングされたオブジェクト（もしあれば）を含むクラフトパックをディレクトリ <dir> に書き込みます。このオプションは --cruft と共に使用された場合にのみ効果があります。git-repack[1] の --expire-to オプションをさらに参照してください。

--prune=<date>

指定された日付より古いルーズオブジェクトをプルーニングします（デフォルトは2週間前、設定変数 gc.pruneExpire で上書き可能）。--prune=now はルーズオブジェクトの古さに関係なくプルーニングし、別のプロセスがリポジトリに同時に書き込んでいる場合、破損のリスクが増加します。以下の「NOTES」を参照してください。--prune はデフォルトでオンです。

--no-prune

ルーズオブジェクトをプルーニングしません。

--quiet

すべての進捗レポートを抑制します。

--force

このリポジトリで別の git gc インスタンスが実行されている可能性がある場合でも、git gc の実行を強制します。

--keep-largest-pack

最大の非クラフトパック、.keep ファイルでマークされたパック、およびクラフトパック以外のすべてのパックが1つのパックに統合されます。このオプションを使用する場合、gc.bigPackThreshold は無視されます。

AGGRESSIVE

--aggressive オプションが指定された場合、git-repack[1] は -f フラグで呼び出され、これは次に --no-reuse-delta を git-pack-objects[1] に渡します。これにより、既存のデルタはすべて破棄され、再計算されますが、再パッキングに多くの時間がかかります。

この効果はほとんど永続的です。例えば、パックとルーズオブジェクトが互いに結合されて1つのパックになった場合、そのパック内の既存のデルタが再利用される可能性がありますが、新しいパックから最適なデルタを選択しない場合など、さまざまなケースもあります。

さらに、--aggressive を指定すると、git-repack[1] に渡される --depth および --window オプションが調整されます。以下の gc.aggressiveDepth および gc.aggressiveWindow 設定を参照してください。より大きなウィンドウサイズを使用することで、より最適なデルタを見つけやすくなります。

このオプションを特定のレポジトリで使用する前に、専用のパフォーマンスベンチマークを実行する価値はおそらくありません。これにははるかに多くの時間がかかり、結果として得られるスペース/デルタの最適化がそれに見合うかどうかは不明です。ほとんどのユーザーとそのレポジトリにとっては、これを使用しないのが適切なトレードオフです。

設定

このセクションのこの行より下のすべての内容は、git-config[1] ドキュメントから選択的に含まれています。内容はそちらで見られるものと同じです。

gc.aggressiveDepth

git gc --aggressive で使用されるデルタ圧縮アルゴリズムの深度パラメータ。デフォルトは50で、--aggressive が使用されていない場合の --depth オプションのデフォルトです。

詳細については、git-repack[1] の --depth オプションのドキュメントを参照してください。

gc.aggressiveWindow

git gc --aggressive で使用されるデルタ圧縮アルゴリズムのウィンドウサイズパラメータ。デフォルトは250で、デフォルトの --window の10よりもはるかにアグレッシブなウィンドウサイズです。

詳細については、git-repack[1] の --window オプションのドキュメントを参照してください。

gc.auto

リポジトリ内にこの数を超えるルーズオブジェクトが存在する場合、git gc --auto はそれらをパックします。一部のポーセリンコマンドは、このコマンドを使用して時々軽量なガベージコレクションを実行します。デフォルト値は6700です。

これを0に設定すると、ルーズオブジェクトの数に基づく自動パッキングだけでなく、gc.autoPackLimit など、git gc --auto が実行すべき作業があるかどうかを判断するために使用する他のすべてのヒューリスティックも無効になります。

gc.autoPackLimit

リポジトリ内に *.keep ファイルでマークされていないパックがこの数より多く存在する場合、git gc --auto はそれらを1つの大きなパックに統合します。デフォルト値は50です。これを0に設定すると無効になります。gc.auto を0に設定すると、これも無効になります。

以下の gc.bigPackThreshold 設定変数を参照してください。これを使用すると、自動パック制限の動作に影響します。

gc.autoDetach

システムがサポートしている場合、git gc --auto をすぐに返し、バックグラウンドで実行するようにします。デフォルトはtrueです。この設定変数は、maintenance.autoDetach が設定されていない場合のフォールバックとして機能します。

gc.bigPackThreshold

ゼロ以外の場合、git gc が実行されるときに、この制限を超えるすべての非クラフトパックが保持されます。これは --keep-largest-pack と非常によく似ていますが、最大のパックだけでなく、しきい値を超えるすべての非クラフトパックが保持されます。デフォルトはゼロです。k、m、または g の一般的な単位接尾辞がサポートされています。

保持されるパックの数がgc.autoPackLimitより多い場合、この設定変数は無視され、ベースパックを除くすべてのパックが再パックされます。その後、パックの数はgc.autoPackLimitを下回り、gc.bigPackThresholdが再び尊重されるはずです。

git repack をスムーズに実行するために推定されたメモリ量が利用できない場合、かつ gc.bigPackThreshold が設定されていない場合、最大のパックも除外されます（これは git gc を --keep-largest-pack と共に実行するのと同じです）。

gc.writeCommitGraph

trueの場合、git-gc[1] が実行されると、gcはコミットグラフファイルを書き換えます。git gc --auto を使用する場合、ハウスキーピングが必要な場合にコミットグラフが更新されます。デフォルトはtrueです。詳細については、git-commit-graph[1] を参照してください。

gc.logExpiry

gc.log ファイルが存在する場合、git gc --auto はその内容を出力し、そのファイルが gc.logExpiry より古くない限り、実行せずにステータスゼロで終了します。デフォルトは「1.day」です。その値を指定する他の方法については、gc.pruneExpire を参照してください。

gc.packRefs

リポジトリで git pack-refs を実行すると、HTTPのような「ダム」なトランスポートを介してGitバージョン1.5.1.2以前でクローンできなくなります。この変数は、git gc が git pack-refs を実行するかどうかを決定します。これはすべてのノンベアリポジトリで有効にするために notbare に設定することも、ブール値に設定することもできます。デフォルトは true です。

gc.cruftPacks

到達不能なオブジェクトをルーズオブジェクトとしてではなく、クラフトパックに保存します（git-repack[1] を参照）。デフォルトは true です。

gc.maxCruftSize

再パック時に新しいクラフトパックのサイズを制限します。--max-cruft-size に加えて指定された場合、コマンドラインオプションが優先されます。git-repack[1] の --max-cruft-size オプションを参照してください。

gc.pruneExpire

git gc が実行されると、prune --expire 2.weeks.ago が呼び出されます（gc.cruftPacks または --cruft を介してクラフトパックを使用している場合は repack --cruft --cruft-expiration 2.weeks.ago も呼び出されます）。この設定変数で猶予期間を上書きします。「now」という値を使用すると、この猶予期間を無効にし、到達不能なオブジェクトを常にすぐにプルーニングできます。「never」という値を使用すると、プルーニングを抑制できます。この機能は、git gc がリポジトリに書き込む別のプロセスと同時に実行される場合の破損を防ぐのに役立ちます。git-gc[1] の「NOTES」セクションを参照してください。

gc.worktreePruneExpire

git gc が実行されると、git worktree prune --expire 3.months.ago を呼び出します。この設定変数を使用して、異なる猶予期間を設定できます。「now」という値を使用すると、猶予期間を無効にして $GIT_DIR/worktrees をすぐにプルーニングできます。「never」という値を使用すると、プルーニングを抑制できます。

gc.reflogExpire
gc.<pattern>.reflogExpire

git reflog expire はこの時刻より古いリフログエントリを削除します。デフォルトは90日です。「now」という値はすべてのエントリを直ちに期限切れにし、「never」という値は期限切れを完全に抑制します。中央に「<pattern>」（例: 「refs/stash」）を使用すると、設定は<pattern>に一致するリファレンスにのみ適用されます。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable

git reflog expire は、この時刻より古く、かつ現在の先端から到達できないリフログエントリを削除します。デフォルトは30日です。「now」という値はすべてのエントリを直ちに期限切れにし、「never」という値は期限切れを完全に抑制します。中央に「<pattern>」（例: 「refs/stash」）を使用すると、設定は<pattern>に一致するリファレンスにのみ適用されます。

これらのタイプのエントリは、通常 git commit --amend または git rebase を使用した結果として作成され、修正またはリベースが発生する前のコミットです。これらの変更は現在のプロジェクトの一部ではないため、ほとんどのユーザーはそれらをより早く期限切れにしたいと考えるでしょう。そのため、デフォルトは gc.reflogExpire よりもアグレッシブです。

gc.recentObjectsHook

オブジェクトを削除するかどうかを検討する際（クラフトパックを生成する場合または到達不能なオブジェクトをルーズとして保存する場合のいずれか）、シェルを使用して指定されたコマンドを実行します。その出力を、Gitが古さに関係なく「最近の」と見なすオブジェクトIDとして解釈します。それらのmtimeを「now」として扱うことで、出力に記載されたすべてのオブジェクト（およびその子孫）は、実際の古さに関係なく保持されます。

出力には、1行に正確に1つの16進オブジェクトIDが含まれ、それ以外は何も含まれてはなりません。リポジトリで見つからないオブジェクトは無視されます。複数のフックがサポートされていますが、すべてが正常に終了する必要があります。そうでない場合、操作（クラフトパックの生成または到達不能なオブジェクトのアンパックのいずれか）は停止されます。

gc.repackFilter

再パック時、指定されたフィルターを使用して特定のオブジェクトを別のパックファイルに移動します。git-repack[1] の --filter=<filter-spec> オプションを参照してください。

gc.repackFilterTo

再パック時、およびフィルターを使用している場合（gc.repackFilter を参照）、指定された場所はフィルター処理されたオブジェクトを含むパックファイルを作成するために使用されます。警告：指定された場所はアクセス可能である必要があります。例えばGitの代替メカニズムを使用するなどしてください。そうでない場合、Gitはそのパックファイル内のオブジェクトにアクセスできない可能性があるため、リポジトリが破損していると見なされる可能性があります。git-repack[1] の --filter-to=<dir> オプションおよび gitrepository-layout[5] の objects/info/alternates セクションを参照してください。

gc.rerereResolved

git rerere gc が実行されると、以前に解決した競合マージの記録はこの日数保持されます。より人間が読みやすい「1.month.ago」なども使用できます。デフォルトは60日です。git-rerere[1] を参照してください。

gc.rerereUnresolved

git rerere gc が実行されると、未解決の競合マージの記録はこの日数保持されます。より人間が読みやすい「1.month.ago」なども使用できます。デフォルトは15日です。git-rerere[1] を参照してください。

注記

git gc は、リポジトリ内のどこかに参照されているオブジェクトを削除しないように非常に注意を払います。特に、現在のブランチとタグのセットによって参照されているオブジェクトだけでなく、インデックス、リモート追跡ブランチ、リフログ（後で修正または巻き戻されたブランチのコミットを参照する可能性があります）、および refs/* 名前空間の他のすべてによって参照されているオブジェクトも保持します。オブジェクトに付けられたノート（git notes によって作成された種類）は、オブジェクトの生存には寄与しないことに注意してください。一部のオブジェクトが削除されることを期待していて削除されない場合は、これらのすべての場所をチェックし、その参照を削除するのがあなたのケースで理にかなっているかどうかを判断してください。

一方、git gc が別のプロセスと並行して実行される場合、別のプロセスが使用しているが参照を作成していないオブジェクトを削除するリスクがあります。これにより、別のプロセスが失敗したり、別のプロセスが後で削除されたオブジェクトへの参照を追加した場合にリポジトリが破損したりする可能性があります。Gitには、この問題を大幅に軽減する2つの機能があります。

  1. --prune 日付より新しい変更時刻を持つオブジェクトは、そこから到達可能なすべてと共に保持されます。

  2. データベースにオブジェクトを追加するほとんどの操作は、オブジェクトが既に存在する場合、オブジェクトの変更時刻を更新し、#1が適用されるようにします。

ただし、これらの機能は完全な解決策には至っておらず、コマンドを並行して実行するユーザーは、破損のリスクをある程度受け入れる必要があります（実際には低いようです）。

フック

git gc --auto コマンドは、pre-auto-gc フックを実行します。詳細については、githooks[5] を参照してください。

関連項目

git-prune[1] git-reflog[1] git-repack[1] git-rerere[1]

GIT

git[1]スイートの一部

scroll-to-top