セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ
デバッグ
メール
外部システム
サーバー管理
-
2.47.0
10/06/24
- 2.43.1 → 2.46.2 変更なし
-
2.43.0
11/20/23
- 2.42.1 → 2.42.3 変更なし
-
2.42.0
08/21/23
- 2.41.1 → 2.41.2 変更なし
-
2.41.0
06/01/23
- 2.38.1 → 2.40.3 変更なし
-
2.38.0
10/02/22
- 2.37.1 → 2.37.7 変更なし
-
2.37.0
06/27/22
- 2.31.1 → 2.36.6 変更なし
-
2.31.0
03/15/21
- 2.30.1 → 2.30.9 変更なし
-
2.30.0
12/27/20
- 2.24.1 → 2.29.3 変更なし
-
2.24.0
11/04/19
- 2.22.1 → 2.23.4 変更なし
-
2.22.0
06/07/19
- 2.21.1 → 2.21.4 変更なし
-
2.21.0
02/24/19
- 2.20.1 → 2.20.5 変更なし
-
2.20.0
12/09/18
- 2.19.1 → 2.19.6 変更なし
-
2.19.0
09/10/18
- 2.18.1 → 2.18.5 変更なし
-
2.18.0
06/21/18
- 2.13.7 → 2.17.6 変更なし
-
2.12.5
09/22/17
-
2.11.4
09/22/17
- 2.10.5 変更なし
-
2.9.5
07/30/17
- 2.7.6 → 2.8.6 変更なし
-
2.6.7
05/05/17
- 2.5.6 変更なし
-
2.4.12
05/05/17
- 2.1.4 → 2.3.10 変更なし
-
2.0.5
12/17/14
概要
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.auto
やgc.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.aggressiveDepth
とgc.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
と非常によく似ています。デフォルトはゼロです。k、m、または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 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はこの時間よりも古い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つの機能があります。
-
--prune
日付よりも新しい変更時間を持つオブジェクトは、そこから到達可能なすべてのものとともに保持されます。 -
オブジェクトをデータベースに追加するほとんどの操作は、オブジェクトが既に存在する場合はオブジェクトの変更時間を更新するため、#1が適用されます。
ただし、これらの機能は完全な解決策には及ばないため、コマンドを同時に実行するユーザーは、破損のリスク(実際には低いようです)を受け入れる必要があります。
HOOKS
git gc --autoコマンドはpre-auto-gcフックを実行します。githooks[5]を参照してください。
GIT
git[1]スイートの一部