ベアリポジトリでgitgcを実行する必要がありますか？
man git-gc 明確な答えがなく、Googleにも運がありませんでした（間違った検索用語を使用していた可能性がありますが）。
ローカルリポジトリでgit gcを実行して、ぶら下がっているオブジェクトを削除したり、履歴を圧縮したりする必要があることを理解していますが、共有のベアリポジトリはこれらの同じ問題の影響を受けやすいですか？
重要な場合、私たちのワークフローは、共有ネットワークドライブ上のベアリポジトリからプルおよびプッシュする複数の開発者です。 「中央」リポジトリはgit init --bare --sharedで作成されました。
Jefromi コメント Danの回答 、git gcshouldベアリポジトリの「通常の」使用中に、自動的に呼び出されます。
積極的に使用されている2つの裸の共有リポジトリでgit gc --aggressiveを実行しました。 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
これらの2つのリポジトリをgcする前に考えていたらよかったのですが、違いを確認するにはgit gcwithout--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を実行すると、このリポジトリに定期的にPushとfetchが移動しますが、count-objectsに明らかに大きな凹みが生じました。しかし、 git config のマンページを読んだとき、デフォルトのルーズオブジェクト制限が6700であることに気付きましたが、これは明らかにまだ到達していません。
したがって、結論はnoであるように見えますが、裸でgit gcを手動で実行する必要はありません必要リポジトリ;* ただし、デフォルト設定のgc.autoでは、ガベージコレクションが自動的に行われるまでに長い時間がかかる場合があります。
*一般的に、git gcを実行する必要はありません。ただし、場合によっては スペースに縛られている可能性があります であり、git gcを手動で実行するか、gc.autoを低い値に設定する必要があります。しかし、私の質問のケースは単純な好奇心でした。
から git-gc manページ：
ユーザーは、このタスクを各リポジトリ内で定期的に実行して、良好なディスクスペース使用率と良好な動作パフォーマンスを維持することをお勧めします。
強調鉱山。ベアリポジトリもリポジトリです！
詳細な説明：ハウスキーピングタスクの1つgit-gcは、緩いオブジェクトのpackingおよびrepackingを実行します。ベアリポジトリにdanglingオブジェクトがない場合でも、時間の経過とともに、多くの緩いオブジェクトが蓄積されます。これらの緩いオブジェクトは、効率を上げるために定期的に梱包する必要があります。同様に、多数のパックが蓄積された場合、それらは定期的に大きな（少ない）パックに再パックする必要があります。
_git gc --auto_の問題は、ブロックされている可能性があることです。
しかし、新しい（Git 2.0 Q2 2014）設定_gc.autodetach_を使用すると、中断することなく実行できるようになります。
commit 4c4ac4d および commit 9f673f9 （ NguyễnTháiNgọcDuy、別名pclouds ）を参照してください。
_
gc --auto_は時間がかかり、ユーザーを一時的にブロックする可能性があります（ただし、それほど煩わしいことではありません）。
それをサポートするシステムでバックグラウンドで実行するようにします。
バックグラウンドで実行すると失われるのはプリントアウトだけです。しかし、_gc output_はあまり面白くありません。
_gc.autodetach_を変更することで、フォアグラウンドに保つことができます。
注：git 2.7（2015年第4四半期）のみがエラーメッセージを失わないであることを確認します。
commit 329e6e8 （2015年9月19日）by NguyễnTháiNgọcDuy（pclouds） を参照してください。
（Merged by Junio C Hamano --gitster- in commit 076c827 、15 Oct 2015）
gc：デーモン化された_gc --auto_からログを保存し、次回印刷しますcommit 9f673f9 （
gc：バックグラウンドで_--auto_を実行するための構成オプション-2014-02-08）は、 '_gc --auto_'がホギングすることに関する苦情を減らすのに役立ちますターミナル、それは別の問題のセットを作成します。このセットの最新のものは、デーモン化の結果、
stderrが閉じられ、すべての警告が失われます。cmd_gc()の最後にあるこの警告は、「_gc --auto_」が繰り返し実行されないようにする方法をユーザーに指示するため、特に重要です。
stderrが閉じているため、ユーザーはわかりません。当然、「_gc --auto_」がCPUを浪費していると不平を言います。Daemonized
gcはstderrを_$GIT_DIR/gc.log_に保存するようになりました。
次の_gc --auto_は実行されず、ユーザーが_gc.log_を削除するまで、_gc.log_が出力されます。
一部の操作はgit gc --autoを自動的に実行するため、git gcを実行するためにneedが存在することはありません。gitがこれを自動的に処理する必要があります。
Bwawokが言ったこととは反対に、ローカルリポジトリとそのベアリポジトリの間には実際には違いがあります（または違いがあるかもしれません）：それを使ってどのような操作を行うか。たとえば、ぶら下がっているオブジェクトはリベースによって作成できますが、ベアリポジトリをリベースしない可能性があるため、オブジェクトを削除する必要はありません（オブジェクトがないため）。したがって、git gcをそれほど頻繁に使用する必要はないかもしれません。しかし、繰り返しになりますが、私が言ったように、gitはこれを自動的に処理する必要があります。
私はgcの論理について100％知りませんが、これを推論するために：
git gcは余分な履歴ジャンクを削除し、余分な履歴を圧縮します。ファイルのローカルコピーには何もしません。
ベアリポジトリと通常のリポジトリの唯一の違いは、ファイルのローカルコピーがあるかどうかです。
ですから、そうです、裸のリポジトリでgitgcを実行する必要があるのは当然だと思います。
個人的に実行したことはありませんが、レポはかなり小さく、まだ高速です。