Git
英語 ▾ トピック ▾ 最新バージョン ▾ git-gc 最終更新日:2.47.0

名前

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

概要

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

説明

現在のリポジトリ内で、ファイルリビジョンの圧縮(ディスク容量の削減とパフォーマンスの向上)、git add の以前の呼び出しによって作成された可能性のある到達不能なオブジェクトの削除、refs のパック化、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.autogc.autoPackLimitなどの設定オプションの制限を超えてハウスキーピングがトリガーされると、rerere、ワーキングツリー、reflogなど、他のすべてのハウスキーピングタスクも実行されます。

--[no-]detach

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

--[no-]cruft

到達不能なオブジェクトの期限切れ処理では、それらをばらばらのオブジェクトとして格納する代わりに、それらをcruftパックにまとめてパックします。--cruftはデフォルトでオンになっています。

--max-cruft-size=<n>

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

--prune=<date>

日付より古いばらばらのオブジェクトをプルーニングします(デフォルトは2週間前、config変数gc.pruneExpireで上書き可能)。--prune=now は、年齢に関係なくばらばらのオブジェクトをプルーニングし、別のプロセスがリポジトリに同時に書き込んでいる場合、破損のリスクが高まります。「NOTES」を参照してください。 --pruneはデフォルトでオンになっています。

--no-prune

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

--quiet

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

--force

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

--keep-largest-pack

最大の非cruftパックを除くすべてのパック、.keepファイルでマークされたパック、cruftパックはすべて単一のパックに統合されます。このオプションを使用すると、gc.bigPackThresholdは無視されます。

AGGRESSIVE

--aggressiveオプションを指定すると、git-repack[1]-fフラグが渡され、git-pack-objects[1]--no-reuse-deltaが渡されます。これにより、既存のデルタが破棄され、再計算されます。これは、リパックにるかに多くの時間を費やすことを犠牲にします。

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

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

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

設定

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

gc.aggressiveDepth

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

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

gc.aggressiveWindow

git gc --aggressiveで使用されるデルタ圧縮アルゴリズムで使用されるウィンドウサイズパラメーター。これは、デフォルトの--windowである10よりもはるかに積極的なウィンドウサイズである250にデフォルト設定されています。

詳細については、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です。このconfig変数は、maintenance.autoDetachが設定されていない場合のフォールバックとして機能します。

gc.bigPackThreshold

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

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

git repack をスムーズに実行するために推定されるメモリ量が不足しており、`gc.bigPackThreshold` が設定されていない場合、最大のパックも除外されます(これは `git gc --keep-largest-pack` を実行した場合と同じです)。

gc.writeCommitGraph

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

gc.logExpiry

gc.log ファイルが存在する場合、そのファイルが `gc.logExpiry` よりも古い場合を除き、git gc --auto はその内容を出力し、ステータス0で終了します。デフォルトは "1.day" です。値の指定方法については、`gc.pruneExpire` を参照してください。

gc.packRefs

リポジトリでgit pack-refsを実行すると、HTTPなどのダムトランスポート経由で1.5.1.2より前のGitバージョンではクローンできなくなります。この変数は、git gcgit 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はこの時間よりも古いreflogエントリを削除します。デフォルトは90日です。"now"という値はすべてのエントリをすぐに期限切れにし、"never"は期限切れを完全に抑制します。間に"<pattern>"(例:"refs/stash")があると、その設定はその"<pattern>"に一致するrefsのみに適用されます。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable

git reflog expireはこの時間よりも古く、現在の先端から到達できないreflogエントリを削除します。デフォルトは30日です。"now"という値はすべてのエントリをすぐに期限切れにし、"never"は期限切れを完全に抑制します。間に"<pattern>"(例:"refs/stash")があると、その設定はその"<pattern>"に一致するrefsのみに適用されます。

これらのタイプのエントリは、一般的にgit commit --amendまたはgit rebaseの使用によって作成され、修正またはリベースが行われる前のコミットです。これらの変更は現在のプロジェクトの一部ではないため、ほとんどのユーザーはそれらをより早く期限切れにしたいと考えており、デフォルトがgc.reflogExpireよりも積極的な理由です。

gc.recentObjectsHook

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

出力には、行ごとに正確に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]を参照してください。

NOTES

git gcは、リポジトリのどこかに参照されているオブジェクトを削除しないように非常に努力しています。具体的には、現在のブランチとタグによって参照されるオブジェクトだけでなく、インデックス、リモート追跡ブランチ、reflog(後で修正または巻き戻されたブランチのコミットを参照する場合があります)、およびrefs/*名前空間のその他すべてによって参照されるオブジェクトも保持されます。オブジェクトに添付されたノート(git notesによって作成されたもの)は、オブジェクトの保持に寄与しません。オブジェクトが削除されると予想されるのに削除されない場合は、これらの場所すべてを確認し、その場合にこれらの参照を削除する必要があるかどうかを判断してください。

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

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

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

ただし、これらの機能は完全な解決策には及ばないため、コマンドを同時に実行するユーザーは、破損のリスク(実際には低いようです)を受け入れる必要があります。

HOOKS

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

GIT

git[1]スイートの一部

scroll-to-top