man git-gcそこには明確な答えがありませんし、Google もうまくいきませんでした (間違った検索用語を使用しただけかもしれませんが)。
ぶら下がっているオブジェクトを整理したり、履歴を圧縮したりするために、ローカルリポジトリで時々実行する必要があることは理解していますgit gcが、共有されているベアリポジトリはこれらと同じ問題の影響を受けやすいですか?
重要な場合、私たちのワークフローは、複数の開発者が共有ネットワーク ドライブ上のベア リポジトリからプルおよびプッシュすることです。「中央」リポジトリは で作成されましたgit init --bare --shared。
JefromiがDan の回答にコメントしたように、ベア リポジトリの「通常の」使用中に自動的に呼び出されるgit gc 必要があります。
git gc --aggressiveアクティブに使用されている 2 つの裸の共有リポジトリで実行しました。1 つは過去 3 ～ 4 週間で約 38 件のコミットがあり、もう 1 つは約 3 か月で約 488 件のコミットがあります。git gcどちらのリポジトリでも手動で実行した人はいません。
$ git count-objects
333 objects, 595 kilobytes
$ git count-objects -v
count: 333
size: 595
in-pack: 0
packs: 0
size-pack: 0
prune-packable: 0
garbage: 0
$ git gc --aggressive
Counting objects: 325, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (325/325), done.
Total 325 (delta 209), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
$ git count-objects -v
count: 8
size: 6
in-pack: 325
packs: 1
size-pack: 324
prune-packable: 0
garbage: 0
$ git count-objects
8 objects, 6 kilobytes
$ git count-objects
4315 objects, 11483 kilobytes
$ git count-objects -v
count: 4315
size: 11483
in-pack: 9778
packs: 20
size-pack: 15726
prune-packable: 1395
garbage: 0
$ git gc --aggressive
Counting objects: 8548, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8468/8468), done.
Writing objects: 100% (8548/8548), done.
Total 8548 (delta 7007), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
$ git count-objects -v
count: 0
size: 0
in-pack: 8548
packs: 1
size-pack: 8937
prune-packable: 0
garbage: 0
$ git count-objects
0 objects, 0 kilobytes
gcこれら 2 つのリポジトリを編集する前に考えておけばよかったのですが、違いを確認するオプションgit gc なしで実行する必要がありました。--aggressive幸いなことに、テストする中規模のアクティブなリポジトリが残っています (2 か月近くで 164 件のコミット)。
$ git count-objects -v
count: 1279
size: 1574
in-pack: 2078
packs: 6
size-pack: 2080
prune-packable: 607
garbage: 0
$ git gc
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1073/1073), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1210), reused 1050 (delta 669)
Removing duplicate objects: 100% (256/256), done.
$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1092
prune-packable: 0
garbage: 0
$ git gc --aggressive
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1742/1742), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1249), reused 0 (delta 0)
$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1058
prune-packable: 0
garbage: 0
このリポジトリを定期的に行き来しているにもかかわらず、ランニングはgit gc明らかに に大きなへこみを作りました. しかし、 のマンページを読んだときに、デフォルトのルース オブジェクトの制限が 6700 であることに気付きました。これにはまだ達していないようです。count-objectspushfetchgit config
したがって、結論はnoのようです。裸のリポジトリで手動で実行する必要はありません。*ただし、 のデフォルト設定では、ガベージ コレクションが自動的に行われるまでに長い時間がかかる場合があります。git gcgc.auto
* 通常、実行する必要はありませんgit gc。ただし、スペースが不足git gcしている場合は、手動で実行するかgc.auto、より低い値に設定する必要があります。ただし、質問に対する私のケースは単純な好奇心でした。
git-gcマニュアルページから：
ユーザーは、各リポジトリ内で定期的にこのタスクを実行して、良好なディスク容量の使用率と良好な動作パフォーマンスを維持することをお勧めします。
鉱山を強調します。ベアリポジトリもリポジトリです！
詳細な説明: 実行されるハウスキーピング タスクの 1 つは、git-gcばらばらのオブジェクトの梱包と再梱包です。裸のリポジトリにぶら下がっているオブジェクトがまったくない場合でも、時間の経過とともに、多くのルーズ オブジェクトが蓄積されます。これらの緩いオブジェクトは、効率のために定期的に圧縮する必要があります。同様に、大量のパックが蓄積された場合は、定期的により大きな (より少ない) パックに再パックする必要があります。
一部の操作は自動的に実行されるため、実行する必要git gc --autoはありません。git が自動的に処理する必要があります。git gc
bwawok が言ったことに反して、実際には、ローカル レポジトリとそのむき出しのレポとの間には違いがあります (またはあるかもしれません)。たとえば、ぶら下がっているオブジェクトはリベースによって作成できますが、裸のリポジトリをリベースしない可能性があるため、それらを削除する必要がない可能性があります (存在しないため)。したがって、それほど頻繁に使用する必要はないかもしれませんgit gc。しかし、繰り返しになりますが、前述したように、git はこれを自動的に処理する必要があります。
gc のロジックについて 100% 知っているわけではありませんが、これを説明するには:
git gc は余分な履歴のジャンクを削除し、余分な履歴を圧縮します。ファイルのローカル コピーには何もしません。
ベア リポジトリと通常のリポジトリの唯一の違いは、ファイルのローカル コピーがあるかどうかです。
したがって、はい、裸のレポで git gc を実行する必要があるのは当然のことだと思います。
個人的に実行したことはありませんが、私のレポはかなり小さく、それでも高速です。