SYNOPSIS

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

DESCRIPTION

ファイルリビジョンの圧縮(ディスクスペースの削減とパフォーマンスの向上)または、「git add」の以前の呼び出しから作成された可能性のある到達不能オブジェクトの削除または、refのパッキングまたは、reflogの剪定(prune)または、メタデータまたは古い作業ツリーのrerere、など、現在のリポジトリ内で多数のハウスキーピングタスクを実行します。 commit-graphなどの補助インデックスも更新される場合があります。

オブジェクトを作成する一般的な磁器コマンド操作を実行すると、最後のメンテナンス以降にリポジトリが大幅に拡張されているかどうかが確認され、拡張されている場合は、 git gc が自動的に実行されます。この動作を無効にする方法については、以下の gc.auto を参照してください。

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

OPTIONS

--aggressive

通常、「git gc」は非常に高速に実行され、ディスクスペースの使用率とパフォーマンスは良好です。このオプションを使用すると、「git gc」はリポジトリをより積極的に最適化できますが、時間がかかります。この最適化の効果は割と持続性があります。詳細については、以下の「AGGRESSIVE」セクションを参照してください。

--auto

このオプションを使用すると、「git gc」はハウスキーピングが必要かどうかを確認します。 そうでない場合は、作業を実行せずに終了します。

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

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

--[no-]cruft

到達不能なオブジェクトを期限切れにするときは、緩いオブジェクトとして保管するのではなく、クラフト・パック(cruft pack)に個別にパックします。 --cruft はデフォルトでオンになっています。

--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) に渡されます。これにより、既存のデルタが破棄されて再計算され、再パッキングに多くの時間を費します。

この効果は割と長続きします。例えばパックとルーズオブジェクトが互いに合体すると、そのパック内の既存のデルタが再利用される可能性がありますが、代わりに新しいパックから次善のデルタを選択する場合もあります。

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

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

CONFIGURATION

このセクションの以下のすべては、 git-config(1) ドキュメントの抜粋です。 内容は 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に設定すると、ルーズオブジェクトの数に基づく自動パッキングが無効にななります。また、他のヒューリスティックな git gc --auto が、 gc.autoPackLimit などの作業があるかどうかを判断するためにこの値を使用します。

gc.autoPackLimit

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

以下の gc.bigPackThreshold 構成変数を参照してください。この設定を使用中は、自動パックの制限がどのように機能するかに影響します。

gc.autoDetach

システムがサポートしている場合は git gc --auto は即座戻り、実行はバックグラウンドで行われます。デフォルトはtrueです。

gc.bigPackThreshold

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

注意: 保持されるパックの数が gc.autoPackLimit を超える場合、この構成変数は無視され、基本パックを除くすべてのパックが再パックされることに注意してください。再パック後、パックの数は gc.autoPackLimit を下回り、再び gc.bigPackThreshold が尊重されるでしょう。

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

gc.writeCommitGraph

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

gc.logExpiry

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

gc.packRefs

リポジトリで git pack-refs を実行すると、HTTPなどの馬鹿プロトコル(dumb transport) を介して 1.5.1.2 より前のGitバージョンではクローンが作成できなくなります。この変数は、「git gc」が「git pack-refs」を実行するかどうかを決定します。これを notbare に設定して、すべての非ベアリポジトリ内で有効にするか、ブール値に設定することができます。 デフォルトは true です。

gc.cruftPacks

到達不能なオブジェクトを緩いオブジェクトとしてではなく、クラフト・パック(cruft pack)(git-repack(1) 参照)に格納します。 デフォルトは true です。

gc.pruneExpire

git gc を実行すると、 prune --expire 2.weeks.ago が呼び出されます(そして gc.cruftPacks または --cruft を介してクラフトパック(cruft packs)を使用している場合は、 repack --cruft --cruft-expiration 2.weeks.ago が呼び出されます)。 この構成変数で猶予期間をオーバーライドします。 値 now を使用してこの猶予期間を無効にし、到達不能なオブジェクトを常にすぐに刈り込み(prune)するか、 never を使用して刈り込みを抑制することができます。この機能は git gc が、リポジトリに書き込む別のプロセスと並列実行される場合の破損を防ぐのに役立ちます。 git-gc(1) の「NOTES」セクションを参照してください。

gc.worktreePruneExpire

git gc が実行されると、 git worktree prune --expire3.months.ago が呼び出されます。この構成変数を使用して、別の猶予期間を設定できます。値「now」を使用して猶予期間を無効にし、 $GIT_DIR/worktrees をすぐに剪定(prune)するか、「never」を使用して剪定を抑制することができます。

gc.reflogExpire
gc.<pattern>.reflogExpire

「git reflog expire」は、この時間より古いreflogエントリを削除します。デフォルトは90日です。値「now」はすべてのエントリをすぐに期限切れにし、「never」は期限切れを完全に抑制します。中央に「<pattern>」(例:「refs/stash」)がある場合、設定は <pattern> に一致するrefにのみ適用されます。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable

git reflog expire は、この時間より古いreflogエントリを削除し、現在の先端(the current tip)から到達不能にします。デフォルトは30日です。値「now」はすべてのエントリをすぐに期限切れにし、「never」は期限切れを完全に抑制します。中央に「<pattern>」(例:「refs/stash」)がある場合、設定は <pattern> に一致するrefにのみ適用されます。

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

gc.recentObjectsHook

オブジェクトを削除するかどうかを検討するとき(クラフト・パックを生成するとき、 または到達できないオブジェクトを緩いオブジェクトとして保存するとき)、 指定のコマンドを実行するためにシェルを使用します。 出力は、その古さに関係なく、 Git が "recent" と見なすオブジェクト ID として解釈されます。 mtime を "now" として扱うことにより、 出力に記載されているすべてのオブジェクト(およびその子孫)は、 実際の古さに関係なく保持されます。

出力は、 1 行あたり 16 進オブジェクト ID が 1 つだけ含まれ、 それ以外は何も含まれない必要があります。 リポジトリ内で見つからないオブジェクトは無視されます。 複数のフックがサポートされていますが、 それら全てのフックが正常に終了(exit)する必要があり、 そうでないと、操作(クラフト・パックの生成または到達不能なオブジェクトの解凍)が停止(halt)します。

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」によって作成された種類の) noteは、オブジェクトの存続に寄与しないことに注意してください。一部のオブジェクトが削除されることを期待していて、削除されない場合は、それらの場所をすべて確認し、それらの参照を削除することが理にかなっているかどうかを判断してください。

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

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

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

ただし、これらの機能は完全なソリューションには及ばないため、コマンドを同時に実行するユーザーは、破損のリスクを抱えて生活する必要があります(実際にはリスクは低いようです)。

HOOKS

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

SEE ALSO

git-prune(1) git-reflog(1) git-repack(1) git-rerere(1)

GIT

Part of the git(1) suite