リポジトリのサイズを減らす

Bitbucket はソース ファイルの保管や変更の管理に最適で、チームでの作業の際にはそのメリットをさらに発揮します。しかしながら、実行ファイルやその他のビルド アーティファクト、動画、その他のメディア ファイルなどの、大規模なバイナリ ファイルの保管には適していません。

アトラシアンのサーバーでユーザーに十分な応答性やダウンロード速度を提供するためにも、リポジトリ サイズを 2.0 GB にすることを推奨しています。Bitbucket Cloud のリポジトリには 4.0 GB の制限があります。この制限に到達した場合、直前のコミットを取り消すための変更のプッシュのみを行えます。

リポジトリのサイズ制限

リポジトリのサイズが 2 GB を超えると、4 GB のリポジトリ サイズ制限の半分を超えたことを知らせる警告が [リポジトリの詳細] パネルに表示されます。Bitbucket で大規模なファイルを保持する必要がある場合、ワークフローの一環として Git Large File Storage (Git LFS) を導入し、BFG を使用してリポジトリを Git LFS に移行することをご検討ください

4.0 GB の制限を上回った場合

サイズが 4.0 GB の制限を上回っている場合、以降はコミットをプッシュすることはできません。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 $ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 406 bytes | 406.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: Repository is over the size limit (4 GB) and will not accept further additions. remote: remote: Learn how to reduce your repository size: https://ja.confluence.atlassian.com/x/xgMvEw. remote: ' To https://bitbucket.org/example/monster.git ! [remote rejected] main -> main (pre-receive hook declined) error: failed to push some refs to 'https://user@bitbucket.org/example/monster.git' $ _

リポジトリが 4 GB の制限を超過した後に最初のプッシュが試行されると、警告メッセージが表示されます。引き続き変更を行うには直前のコミットを取り消す必要があります。詳細については後述の直前のコミットを取り消すをご参照ください。これによって、サイズを 4.0 GB 制限より縮小してプッシュ制限を解除することで、リポジトリのメンテナンスを行えます。

最後のプッシュを取り消す

大規模なファイルを削除するには、履歴を書き換える必要があります。これを行わない場合、Git は大規模なファイルを履歴で保持します。

履歴を巻き戻して大規模なコミットを取り消す

悪影響を与えているコミットを含むブランチを、そのコミットの 1 つ前に巻き戻します。このプロセスでは、悪影響を与えているコミットが 1 つのブランチにのみ存在し、他のブランチにマージされていないと仮定しています。

影響を受けるブランチを使用しているすべてのユーザーに、直前のコミットを取り消すことを伝え、そのコミットをほかのブランチにマージしないように依頼する必要があります。

Bitbucket のリモート履歴は、以下の例のようになります。

1 2 3 4 branch | o---o---o---o <= last (bad) commit in Bitbucket

ローカル履歴は、取り消しが必要なコミットが 1 つのみの場合は以下の例のようになります。

1 2 3 4 5 6 branch | o---o---o---o---o <= last local commit failed to push | reset to here and push

悪影響を与えるコミットを含むブランチで履歴を巻き戻すには、次の操作を実行します。

  1. 任意のローカル コミットを保持するための一時ブランチを作成します。

  2. 元のブランチを、大規模なファイルを含み悪影響を与えるコミットの直前のコミットにリセットします。

  3. 新しい head を Bitbucket にプッシュします (履歴の書き換え)。

  4. ローカルでの変更を復元します。これらはまだプッシュできません。まず大規模なファイルを削除する必要があります。

1 2 3 4 5 git branch <keeper> git reset --soft @{u}^ git push --force git merge --ff-only <keeper> git branch -d <keeper>

--soft オプションを使用することで、未プッシュのすべてのコミットと、未コミットのすべての変更を保持できます。これによって、大規模ファイルの削除が完了したら、それらを後でプッシュできます。保持したい変更がない場合、上述のコマンド ラインの例で --hard オプションを使用して、1、4、5 行目を省略できます。

ガベージ コレクションの自動実行によって不要なコミットが削除される

(リポジトリのサイズ制限を超えていた場合に) 最後のプッシュを取り消すと、ガベージ コレクションが自動で実行され、リポジトリがクリーンアップされます。

Bitbucket のリモート履歴は、以下の例のようになります。

1 2 3 4 5 branch | o---o---o-/-o | dangling commit deleted

これが完了したらプッシュを行えるようになるため、大規模なファイルを削除してリポジトリ サイズを 2.0 GB の制限未満に減らすことができます。後述の「大規模ファイルの削除」をご参照ください。

上記の手順を実行してもリポジトリのサイズが減らない場合はどうすればよいですか?

上記の手順を実行してもリポジトリのサイズが減らない場合は、履歴を書き換えて大規模なファイルを削除する必要が生じる場合があります。大規模なファイルを削除した後、サポート チームに連絡して、GC を実行してもらい、リポジトリのサイズを減らす必要があります。

大規模ファイルの削除

プッシュ制限が解除されたら、リポジトリから大規模なファイルを削除できます。Git リポジトリのメンテナンスや Git LFS の使用の詳細について、次のリソースをご利用いただけます。

追加の LFS ストレージを支払うことなく大量の大規模ファイルを保持したい場合、それらを別の場所に保持する必要があります。利用可能なオプションの一部については「大規模ファイルの保管オプション」をご参照ください。

大規模ファイルを削除したら、リポジトリを使用しているすべてのユーザーが新しいクローンを作成することをおすすめします。これを行わない場合、ほかのユーザーが強制プッシュを行ったときに大規模ファイルが再度プッシュされ、作業をやり直す必要があります。

大規模なコミットの回避

上述のとおり、アトラシアンのサーバーでユーザーに十分な応答性やダウンロード速度を提供するためにも、リポジトリ サイズを 2.0GB 未満に抑えることを推奨しています。大規模なコミットをプッシュしようとするときに次のエラーを回避するためにできることがいくつかあります: remote: fatal: pack exceeds maximum allowed size

  • すでにプッシュの試行に失敗している場合は、最後のコミットをリセットして再試行します。

    • git reset --mixed COMMIT-SHA (これによって、リポジトリ インデックスからこれらの大きなファイルが削除されてステージングされなくなりますが、ローカルでは引き続き利用できます)

    • git status (現在どの変更がステージングされていないかを表示します)

    • `git add file` によって小さな変更を加えて、小さめのコミットを行います。

    • それぞれの小さめのコミットをソースにプッシュします。

  • Git LFS をセットアップして使用します。Bitbucket Cloud による Git LFS の使用方法に関する詳細についてご確認ください。

サイズの大きいファイルの追加を避ける

大規模なファイルを意図せずリポジトリに追加することを防ぐための方法として、いくつかのものが考えられます。

  • 含めたくないファイルを無視するように Git で設定する

  • 自動化を導入して大規模なコミットの作成を防止する

大規模なファイルの無視

ローカル リポジトリを含むディレクトリの .gitignore ファイルに pathname パターンを追加することで、コミットからファイルを除外するように Git に設定できます。 

例:

1 2 3 4 5 6 7 8 9 10 11 # File types to ignore *.exe *.bin *.jar *.war *.mp3 *.mp4 # Directories to ignore target/ .build/ .env/

一般に、次のようなデータを無視するように Git に設定します。

  • ビルド アーティファクト – これらはディレクトリに保管することをおすすめします。たとえば、Maven はこれらを target ディレクトリに保管します。

  • IDE 設定 – これらは通常、リポジトリには不要です。たとえば、.idea ディレクトリを無視します。

  • 依存関係 – 依存関係のキャッシュを除外します。例として、Python の vitrualenv や node のローカル パッケージがあります。

  • メディア ファイル – git リポジトリは大規模な音声または動画ファイルの保管には推奨されません。

大規模なコミットのブロック

大規模なファイルがコミットに含まれるのを防ぐために、各コミットのファイル サイズを確認するローカル フックをインストールして、サイズが大きすぎる場合はコミットを却下できます。

check_added_large_files スクリプトをリポジトリにコピーします。スクリプトを希望通りに実行するために修正できます。次に、リポジトリを使用しているユーザーへの通知を行い、事前コミット フックとしてローカル クローン内のスクリプトへリンクを追加します。

1 ln -s check_added_large_files.py .git/hooks/pre-commit.py

スクリプトのコピーは、リポジトリ内で要件に併せて自由に変更できます。各ユーザーはプルを行ったときに最新のロジックを受信します。

大規模ファイルの保管オプション

Bitbucket リポジトリは、ソース ファイルの保管に最適です。ソースから生成された他のファイルには、それらに適した保管場所を用意することをおすすめします。次のような例があります。

アーティファクト リポジトリの使用

ビルド アーティファクトを保管する多数のサービスがあります。一般的な 2 つの例は次のようなものです。

ビルド プロセスを構成し、ビルド アーティファクトをこれらのリポジトリにアップロードして共有できるようにします。また、ビルド アーティファクトをコミットから除外するように .gitignore が構成されていることを確認します。

Docker リポジトリの使用

Bitbucket リポジトリを実行ファイルのビルドに使用している場合、それらを Docker イメージとしてビルドすることをご検討ください。

ビルド プロセスでイメージを Docker Hubにホストされた Docker リポジトリやローカルの Docker リポジトリにプッシュすることができます。

AWS S3 の使用

大規模なメディア ファイルを Bitbucket リポジトリに保管するのではなく、簡単にダウンロード可能な S3 バケットにアップロードすることができます。

Git LFS の使用

ファイルが Bitbucket リポジトリに必要不可欠の場合、ご利用のプランで利用可能な Large File Storage を使用します。必要に応じてストレージを追加購入できます。

ワイルドカード パターンを使用して、特定のタイプのファイルには LFS を使用するように Git を設定します。

1 git lfs track "<pattern>"

MP4 動画 LFS を使用する場合、次のようになります。

1 git lfs track "*.mp4"

* 上述の例の引用符は重要です。

より効率性の高い Large File Storage に既存の大規模ファイルを移動することで、BFG を使用してリポジトリを Git LFS に移行し、リポジトリのサイズを減らして Bitbucket エクスペリエンスを改善できます。

その他のヘルプ