10

Bitbucket は、私の Git リポジトリが 1 GB を超えていることを警告しています。実際、リポジトリの詳細ページには1.7 GBと表示されています。それはクレイジーです。バージョン管理に大きなデータ ファイルを含めたに違いありません。実際、私のローカル リポジトリは10 GBです。これは、少なくとも.gitignore、大きなファイルをバージョン管理から除外するために、ある程度は正常に使用していることを意味します。

次に、https://confluence.atlassian.com/display/BITBUCKET/Reduce+repository+sizeのチュートリアルに従い、未使用の大きなデータを削除しようとしました。files.git count-objects -v私のレポの最上位フォルダーにあるコマンドは、次の結果を返しました。

count: 5149
size: 1339824
in-pack: 11352
packs: 2
size-pack: 183607
prune-packable: 0
garbage: 0
size-garbage: 0

サイズパック183607 KBは 1.7 GB よりもはるかに小さいです。少し戸惑いました。

次に、BFG Repo Cleaner https://rtyley.github.io/bfg-repo-cleanerをダウンロードし、最上位ディレクトリでコマンドjava -jar bfg-1.12.3.jar --strip-blobs-bigger-than 100Mを実行して、最新ではないすべてのコミットから 100 MB を超えるファイルを削除しました。ただし、BFG は次のメッセージを返しました。

Warning : no large blobs matching criteria found in packfiles 
- does the repo need to be packed?

同じことを 50M 繰り返しても同じ結果になりました。

これは、50 MB を超えるすべてのファイルが最新のコミットにあるということですか? Bitbucket のソース コード ブラウザーで、大きなデータ ファイルを含むフォルダーを確認しましたが、それらのファイルは含まれていません (正常に無視されました)。

リポジトリのサイズとリポジトリ内の大きなファイルの存在に関する混乱の原因は何かを簡単に説明できますか?

4

3 に答える 3

4

以下のように、今日も同じ問題が発生し、 Bitbucket サポートに連絡せずに解決できたと考えています。メソッドはリポジトリから最後のコミットを破棄することに注意してください。そのため、おそらくそのバックアップが必要です。

Bitbucket によると、私たちのレポは約 2.1GB でしたが、クローンを作成すると、ローカルでは約 250MB しかかかりませんでした。このことから、到達不能なコミットの大きなファイルからのものである可能性が最も高いと結論付けました（上記のエドワードの回答に感謝します）。

これは、到達不能なコミットをローカルで確認する方法です。reflog による到達可能性は考慮されていません。

git fsck --unreachable --no-reflog

ローカルで到達できないコミットは、次の方法で消去できます。

git reflog expire --expire-unreachable="now" --all
git prune --expire="now" -v
git gc --aggressive --prune="now"

ただし、Bitbucket でこれらのコマンドをリモートで実行することはできません。しかし、彼らはリポジトリのサイズを減らすことについてのページ(セクションリポジトリの制限を削除する) で、実行(これは最後のコミットを破棄git gcします)に応答して自分自身を実行し、その後に. また、彼らは、死んだデータを収集するガベージのセクションで、次のシーケンスを試すことができると言っています:  ,  ,  . これらすべてを考慮して、次のことをローカルで試すことにしました。reflog を切り取り、ローカルでプルーニングを実行してから、リモートの Bitbucket リポジトリにプッシュし、そこで gc を開始することを期待しています。git reset --hard HEAD~1git push -fgit reflog expire --expire=now --allgit gc --prune=nowgit push --all --force

git reflog expire --expire-unreachable="30m" --all
git prune --expire="30m" -v
git gc --prune="30m"
git reset --hard HEAD~1
git push -f

これは機能し、レポのサイズはすぐに 2.1GB から ca. 250MB。:)

time パラメータ to expire / expire-unreachable / prune は、現在からさかのぼって測定する有効期限のカットオフ ポイントを設定することに注意してください。たとえば、「今」はすべてを期限切れ/削除することを意味し、「30m」は過去 30 分間の変更を除くことを意味します。

編集：

リフレクションで頭に浮かぶことの 1 つは、git はデフォルトで到達不能な reflog エントリを 30 日後に期限切れにするため、コマンド シーケンスが を実行したためではなく、git reflog expireローカルで (おそらくリモート リポジトリにプッシュされなかった)動作した可能性があるということです。によってトリガーされたリモートは、30日以上経過した到達不能なコミットをすべて削除したためです。git prunegit gcgit gcgit reset

したがって、次のことが私に同じ効果をもたらした可能性があります。

git reset --hard HEAD~1
git push -f

また、過去 30 日間に行われたアクセスできない変更については、Bitbucket サポートに連絡する必要があります。

于 2016-05-16T11:45:45.527 に答える
0

私は Jan の答えを試しましたが、私の場合はdid not trigger がgit reset --hard HEAD~1続きました。git push -fgit gc

問題をAtlassian コミュニティに投稿することになり、Atlassian の人が駆けつけgit gcて問題が解決しました。彼らの反応は遅くなかったので（〜3時間）、私はこの方法をお勧めします.

于 2018-07-04T10:00:50.810 に答える