何年も前にチェックインされた多数の大きなブロブが原因で、リポジトリが非常に大きくなりました。それらはその後の改訂で削除され、もはや必要ないので、それらへの参照を今すぐ削除できるはずです。
使用に関するいくつかの参照を見てきましgit filter-branchたが、このコマンドを使用すると危険で厄介なように見えるので、これを試しました：
git checkout --orphan new-master
git rm -rf --cached *
git merge --squash master
git branch -D master
git gc --prune=now
これは、履歴の任意の時点で作成され、その後削除されたものはすべて永久に削除されることを意味するのではないでしょうか?
何らかの理由で、動作していないようです - サイズはほぼ同じです。
助言がありますか？
申し訳ありませんがfilter-branch、これを行う唯一の方法です。
緊張している場合は、リポジトリの別のクローンでテストしてみてください。これを行うと、git がすべてをバックアップすることを覚えておいてください。そのため、変更された履歴をプッシュするまで、複製されたリポジトリのサイズがローカルで増加します。
この に関する GitHub の便利なページをチェックしてみます。
また、私の恥知らずなプラグインをお許しいただければ、私は最近、履歴と作業コピーの両方で大きなファイルに関するいくつかの基本的なメトリックを提供するRuby gemに取り組んでいます。これはまだ活発に開発されていますが、うまく機能し、役に立つことを願っています。
まず、git は分散型のリビジョン管理システムです。つまり、clone. したがって、git checkout <commit-sha>リポジトリの履歴内の任意のコミットに対して for を実行して、過去のある時点でのリポジトリがどのようなものであったかを正確に取得できます。
新しいブランチを作成しても、リポジトリの履歴から解放されるわけではありません。実際、ブランチは commits へのポインターにすぎません。簡単にするために、すべてのブランチには共通の祖先があるため、new-masterブランチは古いブランチとまったく同じmasterです。サイズのわずかな減少は、おそらく git がガベージ コレクションから最適化をわずかに改善したことによるものでしょう。
あなたが実行したときgit gc --prune=now、あなたはloose objectsあなたのpackfile. Apackfileは、効率を高めてリポジトリのサイズを縮小するために、git が効率的にオブジェクトを格納する場所です。詳細については、こちらをご覧ください。
あなたが git の新参者である場合、参加することはたくさんありますが、私は高レベルの概要を提供しようとしました. 優れた git ドキュメントを調べて、そのgit filter-branchコマンドを無効にして、リポジトリのサイズを縮小することに真の意味で影響を与える準備をします。