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

Bitbucket is great for keeping your source files and managing changes, especially when working on a team, but it's not the best place to keep large binary files, such as executables and other build artifacts, or videos and other media files.

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

Bitbucket で大規模なファイルを保持する必要がある場合、ワークフローの一環として Git Large File Storage (Git LFS) を導入し、BFG を使用してリポジトリを Git LFS に移行することをご検討ください。

リポジトリのサイズ制限

これらの制限をサイズが上回った場合、[リポジトリの詳細] パネルに警告が表示されます

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

1.0 GB の制限を上回っている場合、コミットをプッシュすると、コマンド ラインに次のような警告が表示されます。

$ git push 
Enumerating objects: 5, done. 
Counting objects: 100% (5/5), done. 
Delta compression using up to 12 threads 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (3/3), 332 bytes | 332.00 KiB/s, done. 
Total 3 (delta 0), reused 0 (delta 0) 
remote: This repository is currently 1.0 GB in size. If it exceeds 2 GB it will be put into read-only mode. 
remote: Learn how to reduce your repository size: https://confluence.atlassian.com/x/xgMvEw 
To https://bitbucket.org/example/monster.git 
	3db4505..0393b72 master -> master 
$ _

この警告が表示された場合、リポジトリのメンテナンスを行って大規模なファイルを削除してください。詳細については後述の「大規模なファイルを削除する」をご参照ください。

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

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

$ 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: b'Repository is over the size limit (2 GB) and will not accept further additions.
remote: 
remote: Learn how to reduce your repository size: https://confluence.atlassian.com/x/xgMvEw.
remote: '
To https://bitbucket.org/example/monster.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://user@bitbucket.org/example/monster.git'
$ _

引き続き変更を行うには、直前のコミットを取り消す必要があります。後述の「最後のプッシュを取り消す」をご参照ください。これにより、サイズを 2.0 GB 制限よりも小さくし、プッシュ制限を解除して、リポジトリのメンテナンスを行うことができます。

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

5.0 GB を上回った場合、すべての変更が却下されます。サポート リクエストを起票して、リポジトリのサイズを縮小するための支援を依頼する必要があります。

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

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

tip/resting Created with Sketch.

Before doing these steps, you can enable the Delete dangling commits when over size limit feature in Labs to trigger garbage collection automatically.

This will delete the large files you remove from history when you rewind your branch head, avoiding the need to submit a Support request.

Rewind history to undo large commits

悪影響を与えているコミットを含むブランチをその 1 つ前のコミットに巻き戻し、直前のコミットを取り消して、リポジトリ サイズを制限未満にします。このプロセスでは、悪影響を与えているコミットが 1 つのコミットにのみ存在し、ほかのブランチにマージされていないと仮定しています。

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

Remote history in Bitbucket looks similar to the following example:

			branch
            |
o---o---o---o <= last (bad) commit in Bitbucket

Local history might look similar to the following example, assuming you only need to undo one commit:

  			branch
            |
o---o---o---o---o <= last local commit failed to push
        |
        reset to here and push

To rewind history on the branch containing the bad commit:

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

  2. Reset the original branch to the commit just before the bad commit containing the large files.

  3. Push the new head to Bitbucket (rewriting history).

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

git branch <keeper>
git reset --soft @{u}^
git push --force
git merge --ff-only <keeper>
git branch -d <keeper>

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

Run garbage collection to delete dangling commits

If you enabled the Labs feature (see tip above), the bad commits will be deleted by automatic garbage collection and your repo size should be reduced in a few minutes.

Otherwise you'll need to raise a Support request in order to run garbage collection to delete the bad commits that are no longer in the history and reduce the repository’s size.

Remote history in Bitbucket should now look similar to the following example:

		branch
        |
o---o---o-/-o
            |
            dangling commit deleted

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

大規模ファイルの削除

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

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

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

大規模なコミットの回避

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

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

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

大規模なファイルの無視

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

例:

# 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 リポジトリは大規模な音声または動画ファイルの保管には推奨されません。

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

To prevent any large files getting included in commits, you can install a local hook that checks the size of files in every commit and will reject the commit if it is too large.

check_added_large_files フックから開始します。これをリポジトリにコピーして、すべてのユーザーが自身のローカル リポジトリでコミット前のフックとして追加できるようにします。

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 を設定します。

git lfs track "<pattern>"

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

git lfs track "*.mp4"

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

tip/resting Created with Sketch.

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

最終更新日 2020 年 5 月 21 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.