どのくらいの頻度でgit-gcを使用すべきですか？
マニュアルページは、単純に言います：
ユーザーは、各リポジトリ内でこのタスクを定期的に実行して、ディスク領域の使用率と運用パフォーマンスを維持することをお勧めします。
オブジェクトの数を取得して、GCの時間かどうかを確認するコマンドはありますか？
回答:
これは主に、リポジトリが使用される量に依存します。1人のユーザーが1日に1回チェックインし、ブランチ/マージ/その他の操作を週に1回行うので、おそらく1年に1回以上実行する必要はありません。
数十人の開発者が1日に2〜3回チェックインする数十のプロジェクトに取り組んでいるので、毎晩実行することができます。
ただし、必要以上に頻繁に実行しても問題はありません。
私がやろうとしていることは、今それを実行し、それから1週間後にディスク使用率を測定し、再度実行して、ディスク使用率を再度測定することです。サイズが5％低下した場合は、週に1回実行します。それがさらに落ちる場合は、より頻繁に実行してください。低下が少ない場合は、実行頻度を減らします。
リポジトリのガベージコレクションの欠点は、ガベージが収集されることです。私たち皆がコンピューターユーザーとして知っているように、私たちが現在ゴミと見なすファイルは、3日後に非常に貴重なものになる可能性があります。gitが残骸のほとんどを保持しているという事実は、私のベーコンを数回節約しました-ぶら下がっているすべてのコミットを参照することで、誤って缶詰にしていた多くの作業を回復しました。
だから、あなたのプライベートなクローンにきちんとしたフリークになりすぎないでください。それはほとんど必要ありません。
OTOH、データの復旧可能性の価値は、主にリモートとして使用されるリポジトリに疑問があります。すべての開発者がプッシュしたりプルしたりする場所。そこで、GCの実行と再パックを頻繁に開始するのが賢明な場合があります。
git gc --help特に、--pruneオプションを参照）。についての説明もありgc.reflogExpireます。このため、過去90日間に訪問したコミットメントは収集されないと思います。（私のgitバージョン：v1.7.6）
gitの最近のバージョンでは、必要に応じてgcが自動的に実行されるため、何もする必要はありません。man git-gc（1）の「オプション」セクションを参照してください：「一部のgitコマンドは、多数のルーズオブジェクトを作成する可能性のある操作を実行した後にgit gc --autoを実行します。」
gc --autoないでください。
Git-Guiを使用している場合は、いつ心配する必要があるかがわかります。
This repository currently has approximately 1500 loose objects.
次のコマンドは同様の数をもたらします：
$ git count-objects
ソースを除いて、git-guiはそれ自体で計算を行い、実際には.git/objectsフォルダーで何かを数え、おそらく近似をもたらします（tcl適切に読み取ることはわかりません！）。
いずれの場合においても、思われる任意の数に基づいて、警告を与えるために周りに 300個の緩いオブジェクトを。
Git-Gui、count-objectsここでの質問に対する正確な回答ではありません...しかし、それらは正しいはずです！
新しい（Git 2.0 Q2 2014）設定で、中断することなくそれを行うことができますgc.autodetach。
commit 4c4ac4dとcommit 9f673f9（NguyễnTháiNgọcDuy、別名pclouds）を参照してください。
gc --auto時間がかかり、ユーザーを一時的にブロックする可能性があります（ただし、それほど煩わしくはありません）。
それをサポートするシステムのバックグラウンドで実行するようにします。
バックグラウンドでの実行で失われる唯一のものは、プリントアウトです。しかしgc output、本当に面白いわけではありません。
を変更することで、フォアグラウンドに保つことができgc.autodetachます。
その2.0リリース以降、バグがありましたが、git 2.7（2015年第4四半期）ではエラーメッセージが失われないようになっています。
参照してください329e6e8コミットにより（2015年9月19日）のグエンタイ・ゴックDuyと（pclouds）。
（合併によりJunio C浜野- gitster-で076c827コミットし、2015年10月15日）を
gc：デーモン化されたものからログを保存しgc --auto、次回印刷する一方でコミット9f673f9（
gc：実行するための設定オプション--autoバックグラウンドで- 2014年2月8日）は「に関するいくつかの苦情減らすことができますgc --auto」末端を占有し、それが問題の別のセットを作成します。このセットの最新のものは、デーモン化の結果として
stderr閉じられ、すべての警告が失われます。の最後に表示されるこの警告は、cmd_gc()「gc --auto」の繰り返し実行を回避する方法をユーザーに通知するため、特に重要です。
stderrが閉じているため、ユーザーにはわかりません。当然、「gc --auto」がCPUを浪費していると文句を言います。デーモン化
gcはに保存さstderrれ$GIT_DIR/gc.logます。
以下gc --autoはgc.log、ユーザーが削除するまで実行および印刷されませんgc.log。
この引用は、 Gitによるバージョン管理
Gitはガベージコレクションを自動的に実行します。
•リポジトリに緩いオブジェクトが多すぎる場合
•リモートリポジトリへのプッシュが発生したとき
•多くの緩いオブジェクトを導入する可能性があるいくつかのコマンドの後
•git reflogなどの一部のコマンドが期限切れになり、明示的に要求した場合
そして最後に、git gcコマンドを使用して明示的に要求すると、ガベージコレクションが発生します。しかし、それはいつなのでしょうか？この質問に対する明確な答えはありませんが、いくつかの良いアドバイスとベストプラクティスがあります。
いくつかの状況では、git gcを手動で実行することを検討する必要があります。
•git filter-branchを完了したばかりの場合。filter-branchは多くのコミットを書き換え、新しいコミットを導入し、結果に満足したら削除すべき参照に古いコミットを残していることを思い出してください。それらのすべての死んだオブジェクト（それらを指す1つの参照を削除したため参照されなくなった）は、ガベージコレクションを介して削除する必要があります。
•多くの緩いオブジェクトを導入する可能性があるいくつかのコマンドの後。これは、たとえば、大規模なリベース作業になる可能性があります。
反対に、ガベージコレクションに注意する必要があるのはいつですか。
•回復したい孤立した参照がある場合
•git rerereのコンテキストでは、解像度を永久に保存する必要はありません
•Gitがコミットを永続的に保持するのに十分なタグとブランチのみのコンテキストで
•FETCH_HEAD取得（git fetchによるURL直接取得）のコンテキストでは、ガベージコレクションの対象となるため
git commit --amend）ツリーに到達できないコミットがあります。これはで確認できますgit log --reflog。ブランチをリモートリポジトリにプッシュし、ツリーをもう一度チェックしました。到達できないコミットがまだ残っていました。どうやらgit gcこのプッシュが起こったときに実行されませんでした。…？
あなたは使用する必要はありませんgit gcので、非常に多くの場合git gc（ガベージコレクション）がいくつかの頻繁に使用するコマンドで自動的に実行されます。
git pull
git merge
git rebase
git commit