Bitbucketの容量制限を解消した話

[04/01, 2025]

塵も積もれば山となる。こんにちは、トモです。
BitBucketに十年くらいお世話になっているのですが、今年から？無料プランのワークスペースの合計容量が１Gまでの制限が設けられました。
１月にアナウンスされ、４月２８日ごろに執行されるようです。

自分は溜まり溜まった思い出とログが、18Gくらいになっていました😅

これはそんな思い出とログを断捨離したお話です。

⚠️注意
gitのログを改変したり削除するコマンドが出てきます。
試す際はバックアップを必ずとってから試すことをお勧めします。
あくまで自分の場合のやり方です。ご自身の環境に合わせて参考程度にしてください。

まずは結論

結論を先に書くと

容量の大きいリポジトリから順に以下を検討・実行しました。

Unity系で使ってないリポジトリはアセットの容量が大きいので諦めた（ローカルに保存した）
不要なリポジトリの削除
同じ名前で作り直してログをゼロからのスタート
あわせて.gitignoreを見直した
Podsの除外
PSDファイルも管理対象から外す

を行いました。

17.8Gあった容量は、無事600Mを切るまでになり、さらにまだ追加の圧縮も見込めそうな状況にまで来ています。

メールが来た

先にも書いた通り、無料プランを十年ほど使用させいただいております。（ほんと感謝）
そんな中３月２８日にメールが届きました。
「Your workspace is over 1 GB」というメールが届きました。
ようはリミット超えてるから減らすか、有料プランに移行してねというお知らせです。

1月にアナウンスされた際にもちゃんとメールはきていたのですが
「 Repository storage limit: free workspaces will now have a total storage limit of 1 GB.」
という部分だけ読んで、1G超えてるリポジトリないし大丈夫かなーと思っていたのと、
まだこの時は「リポジトリの容量」が「ワークスペース容量」を指していることに気づけていませんでした。

選択肢

選択肢は

お金払う
GitHubへ移行
一部GitHubへ移行してBitbucketと併用
リポジトリの整理・圧縮をして1G以下にする

が考えられます。

全然意識していなかったのですが、放置してしまった非アクティブなリポジトリも含め１７０以上リポジトリがあったので、正直以降や整理は手間がかかるのは目に見えています。

有料プランの上限を問い合わせてみた

Bitbucketの価格ページなどで、有料プランの容量制限を調べたのですが、ワークスペース全体の容量制限がどれくらいかわからなかったので問い合わせてみました。

Atlassianは日本語ページやサポートが手厚いの素晴らしいですよね。メールをすると１営業日くらいで返事を返してくださいました。

やり取りの中で分かったことは、

有料版の上限は4Gまで
説明ページの「リポジトリサイズ」とは「Bitbucket 上にあるリポジトリの合計サイズ」と定義されている

ということでした。つまり、ワークスペースの容量上限は4Gまでのようです。
そしてこの時、１月のメールのRepositoryの意味がgitのリポジトリではなく、ワークスペース全体を指していることを認識しました😅

自分のワークスペースの合計容量が17.8Gだったので、有料プランにするだけでは何も解決しないこともわかりました😭

圧縮することにした

あまりGitに詳しいわけでなかったのですが、調べながらテストしてみた感じ
17.8Gを4Gにするのと1G以下にするのは作業内容や手間があまりが変わらない感じがしたので、
頑張って１Gまで整理・圧縮することにしました。

まずはバックアップ

まずは全部のリポジトリをローカルにCloneして、SSDに保存しました。
これで最悪失敗しても元に戻せます😀
全部のCloneも、BitBucketにDL機能やスクリプトがあればいいのですが、ちょっと分からなかったので、取り急ぎ手動でやりました😇

原因の調査

次に容量が大きい原因を調査します。

やるべきことは

容量の大きいリポジトリを探す
なんで容量が大きいかを探す
容量の大きいリポジトリを探す

Bitbucketにはリポジトリのサイズ順にリポジトリを並べる機能がありません。
また、リポイジトリ一覧にはリポジトリのサイズが表示されません。（なんで〜？）
ただBitBucketではWorkspace > Project > Repositryという階層になっていて、Projectのリポジトリ一覧では容量が表示されます。
（ただし並び替えはできません）

なので

Cloneした全リポジトリを１つのフォルダに入れておいたので、ターミナルで

du -hd1 | sort -hr

を打つことでサイズとフォルダ名を大きい順に並べて確認しました。

なんで容量が大きいかを探す

といっても自分ではなんとなく想像はついていて

.gitignoreがちゃんとしていない
CocoaPodsのPodフォルダがadd.commitされてしまっている
Unity系のプロジェクトのリポジトリはアセットが重たい

ということです。
Unity系のリポジトリは１で並べた時に上位に並んでいましたし、明白でした。

なので

.gitがどれくらい大きいか？
.gitが大きい理由は何か？

を容量の大きいリポジトリで調べました。

.gitがどれくらい大きいか？

.git以外にもそもそもリポジトリの中で何の容量が大きいかを調べました。

(du -hd1; du -hs *) | sort -hr

macでドンピシャなやり方が分からず自分は上記のコマンドを使いました。
フォルダ・ファイルの大きい順の表示してくれるのですが、duを２回行っているので、フォルダがダブって表示されてしまいます。
ただ、容量の確認には困らなかったのでそのまま使いました。
何かいい方法があれば教えてください笑

予想通り.git PSDファイル Podsフォルダが大体大きいことが多かったです。

.gitは2-300M位になっていました。また、広告系のSDKはバイナリが含まれていることもあるせいか、Podsフォルダはローカルで100Mくらいになることもありました。

.gitが大きい理由は何か？

ChatGPTに聞いたら「git_find_big.sh」を使えと教えてくれました。
ただローカルにそんなコマンドや、ファイルは無く「git_find_big.sh」ってなに？
と聞くと

「git_find_big.sh は、Git リポジトリ内の大きなファイルを特定するためのスクリプトです。
このスクリプトは、Atlassian のドキュメント「Maintaining a Git Repository」で公開されていましたが、
現在そのページは削除されているようです。ただし、GitHub 上のいくつかのリポジトリで git_find_big.sh のコピーが公開されています。」

とのこと。こんなところでAtlassianが出てくるとは。。。w

自分はこのGitHubのgit_find_big.shを使用させてもらいました。

.gitのあるフォルダでgit_find_big.shを叩くと

-e     size   pack                                      SHA                                                                                                          location
70154  31284  f789b7b2b49e117efc141b769f716c22a21c3c0e  Pods/XXXX(省略)
65726  31464  f2dba0cbcd7d022f59b0f69d8508c8efb3ced3d9  Pods/XXXX(省略)

こんな感じにobject?pack?ごとに大きい順でTop10を表示してくれます。

これもまた大体予想どおり、Podsフォルダがそのままcommitされてログが残っていたり、PSDファイルが入っていて肥大化していました。

.gitの圧縮

先に言うと最終的に自分は.gitの圧縮（ログの修正）ではなくリポジトリの作り直しを選択しました。

Gitに詳しくないのでGPTに聞きながらやろうと思い提案された中から
「filter-repo」を使う方法をやってみました。

ざっくり言うと

git filter-repo --path Pods --invert-paths --force

これでPodsの履歴が.gitから消えます。ただしPodsフォルダの実態も消えてしまいます。
なのでPodsはいいですがPSDファイルなどは消えたら困るので、1度退避させてから行う必要があります。

自分はこれに気づかず最初「お、どんどんフォルダ軽くなってくじゃん！」なんてワクワクしながらやってましたが、ログだけで無くフォルダの中身もどんどん空っぽになっていってました😅
バックアップをとってローカルに対して行っていたのでいいですが、リモートにpushしていたら大変なことになってましたね。

バックアップから丸っと元に戻してから一旦テストで、Podsのログだけを削除して、リモートに強制pushしてみました。

すると、最初450Mほどのリポジトリが490Mに増えてしまっていました。
色々検索すると同じようなことが起こっている方がいらっしゃいました。
https://entersquare.jp/web-develop/484/

１時間以上経っても容量が減らない場合は、サポートに連絡するとgit gcなどを手動で（たぶん）叩いてくれるような雰囲気でした。
実際１時間以上待ってもテストしたリポジトリの容量は減りませんでした。

自分の場合は

リポジトリの数が多い
全部終わってから連絡して、もしも容量が減らなかったら困る（気力も尽きる）

ので違うやり方でやることにしました。

リポジトリを作り直すことにした

.gitの圧縮のテスト作業をしながら、「これ最低数十回はやらないといけないけどすごいめんどくさいなー」なんて思い他のやり方も模索していました。
そしてそもそも、ロールバックやリバートが必要ないのであれば、新規リポジトリを作って０からのスタートでいいのでは？
と言う結論に至りました。

同じ名前で作り直してコミットするとちゃんと容量が減る
タイポしているリポジトリ名があったので直せる
ブランチ名のmaster -> mainの変更が同時にできる
リポジトリによっては200M -> 1M程度に圧縮できる

などの理由からこの方法を取ることにしました。

やり方は、そのまんまですが

Cloneする
.gitの削除 & git init
.gitignoreの生成
PSDファイルはローカルへ退避
BitBucketのリポジトリの削除 & 作成
remoteの追加 & push
新しいリポジトリからcloneしてビルドして通ればOK

と言うやり方で進めました。

ついでと言ってはなんですが、対象リポジトリの初期commitを見ながら、「ちょうど十年前の今頃コミットしたのかー」なんて思い出に浸りながら削除してました笑

全177リポジトリでは無く、大きい順にやっていって、ワークスペースの容量を確認しながら進めたので
50個くらいのリポジトリに対して行うことで概ね目標を達成できました。

それでも、相当な手間と忍耐力が必要でした😅

リポジトリの作り直しでハマったこと

同じ名前でリポジトリを作り直しているので、CocoaPodsやSPMのURLも変わらずそのまま使えます。
ただSPMのキャッシュ周りで１点エラーになりハマりました。

エラー内容は

Revision ハッシュ値A for YYY remoteSourceControl SPMのURL version 0.0.0 does not match previously recorded value ハッシュ値B

で、同じライブラリ、バージョンなのにハッシュ値が異なってるよ的なエラーが出ました。
キャッシュの問題なの分かっていたのですが、Xcodeから何度「Reset Package Caches」を呼んでも解決せず

このSwift Packageのキャッシュを根こそぎ削除するを試したら無事ちゃんと認識してくれるようになりました。

自分の場合はProjectのルート配下の全ての*/Package.resolvedの削除

find . -name Package.resolved | xargs rm -rf

が直接的に聞いてるようでした。

自分はSPMをまとめて管理するためのSPMを１つ入れてそこから呼び出しているのですが、その１つのPackage.resolvedを削除しただけではうまく認識してくれなかったので「ルート配下の全ての*/Package.resolved」って言うのがキモだったようですね。

PSDファイルなどは要検討

一旦リポジトリから外したPDSファイルは、要検討と言うか宿題として残っています。
GLFSを使うと言う手もあるかもしれませんし、GoogleDriveなどに入れると言う手もあると思います。

個人的にはスマホアプリのリポジトリの場合はPSDファイルなども揃っていて欲しいなと思うので、リポジトリに入れたいなーともやモヤモヤしています。

ですがひとまず、容量制限もクリアして、ひと段落できてよかったです🎉