正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

リポジトリサイズ

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

Gitリポジトリのサイズは、パフォーマンスとストレージコストに大きく影響する可能性があります。圧縮、ハウスキーピング、その他の要因により、インスタンスごとに若干異なる場合があります。

サイズの計算

プロジェクトの概要ページには、リポジトリファイル、アーティファクト、LFSなど、リポジトリ内のすべてのファイルのサイズが表示されます。このサイズは15分ごとに更新されます。

リポジトリのサイズは、リポジトリ内のすべてのファイルの累積サイズを計算することによって決定されます。この計算は、リポジトリのハッシュ化されたストレージパスでdu --summarize --bytesを実行するのと似ています。

サイズとストレージの制限

管理者は、GitLab Self-Managedのリポジトリサイズ制限を設定できます。GitLab SaaSの場合、サイズ制限は事前定義されています。

プロジェクトがサイズ制限に達すると、プッシュ、マージリクエストの作成、LFSオブジェクトのアップロードなどの特定のオペレーションが制限されます。

Git履歴を書き換える前に

Git履歴を書き換え、リポジトリからデータを削除する前に、以下のセクションの情報を考慮に入れる必要があります。

ローカルクローンを変更する必要があります

リポジトリのクローンを持つすべてのユーザーは、次のいずれかを行う必要があります:

  • ローカルコピーを削除し、リポジトリの新しいコピーをクローンします。
  • すべてのリモート変更をフェッチし、進行中のすべての作業がその上にリベースされていることを確認します。

適切に行わないと、ローカル変更をプッシュするユーザーによって、削除されるべきファイルが復活する可能性があります。

実行中のパイプラインがクリーンアップを失敗させる可能性があります

クリーンアップ中にパイプラインがまだ実行されている場合、それらはリポジトリと対話し、クリーンアップが適切に機能しない原因となる可能性があります。

ガベージコレクションの猶予期間

GitLabは、30分の猶予期間でGitガベージコレクションを実行します。このプロセスは、次の両方のオブジェクトをクリーンアップします:

  • いずれの参照からも到達不能。
  • 少なくとも30分以上経過している。

削除したいデータがコミットから到達可能であるか、30分未満である場合、Gitガベージコレクションはそれを削除しません。

その結果、ハウスキーピングを実行した後、到達不能オブジェクトを排除するを選択する前に少なくとも30分待つ必要があります。

フォークしたプロジェクトでは履歴を書き換えることはできません

組み込みメソッドは、フォークしたリポジトリでは使用できません。GitLabオブジェクトがフォーク間で保存される方法により、Gitがフォーク間で共有されるオブジェクトをガベージコレクションすることは不可能です。

回避策: プロジェクトをアーカイブする

クリーンアップを行う前にアーカイブすると、リポジトリは読み取り専用になります。これにより、クリーンアップの進行中に誰も変更を加えることがなくなります。

リポジトリをアーカイブすると、フォークの関係も削除されます。これにより、データをクリーンアップできます。しかし、データがフォークにプルされた場合、そこでもクリーンアップが必要になります。

リポジトリサイズを削減する方法

リポジトリのサイズを削減するには、次の方法を使用できます。

リポジトリのサイズを小さくする前に、リポジトリの完全バックアップを作成する必要があります。これらの方法は元に戻すことができず、プロジェクトの履歴とデータに影響を与える可能性があります。

利用可能な方法でリポジトリのサイズを小さくする場合、プロジェクトへのアクセスをブロックする必要はありません。プロジェクトがユーザーにアクセス可能な状態のまま、これらのオペレーションを実行できます。これらの方法には、既知のパフォーマンスへの影響はなく、ダウンタイムも発生しません。ただし、ユーザーへの影響を最小限に抑えるために、アクティビティの低い期間中にこれらのアクションを実行する必要があります。

リポジトリの履歴からファイルをパージ

git filter-repoを使用してファイルをパージして、Gitの履歴から大きなファイルを削除できます。パスワードやキーなどの機密データを削除するために、この方法を使用しないでください。代わりにblobを削除するか、テキストを削除するを使用してください。

このプロセス:

  • Gitの履歴全体を変更します。
  • オープンマージリクエストに影響を与える可能性があります。
  • 既存のパイプラインに影響を与える可能性があります。
  • ローカルリポジトリの再クローンが必要です。
  • LFSオブジェクトには影響しません。
  • コミット署名を指定しません。
  • 元に戻すことはできません。

ファイルコンテンツを含むコミットに関する情報はデータベースにキャッシュされ、リポジトリから削除された後も表示されます。

リポジトリのクリーンアップ

このメソッドを使用して、リポジトリから内部Git参照と参照されていないオブジェクトを削除します。機密データを削除するために、この方法を使用しないでください。機密情報を削除するには、blobを削除する方法を使用してください。

このプロセス:

  • git gc --prune=30.minutes.agoを実行して、参照されていないオブジェクトを削除します。
  • 未使用のLFSオブジェクトのリンクを解除し、ストレージ容量を解放します。
  • ディスク上のリポジトリサイズを再計算します。
  • 元に戻すことはできません。

内部Git参照を削除すると、関連するマージリクエストのコミット、パイプライン、および変更の詳細が利用できなくなります。

前提条件:

  • 削除するオブジェクトのリスト。git filter-repoを使用して、commit-mapファイル内のオブジェクトのリストを作成します。

リポジトリをクリーンアップするには:

  1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。

  2. 設定 > リポジトリに移動します。

  3. リポジトリの保守を展開します。

  4. 削除するオブジェクトのリストをアップロードします。たとえば、filter-repoディレクトリ内のcommit-mapファイルなどです。

    commit-mapファイルが大きすぎると、バックグラウンドのクリーンアッププロセスがタイムアウトして失敗する可能性があります。その結果、リポジトリのサイズは期待どおりに縮小されません。これに対処するには、ファイルを分割して、パーツごとにアップロードします。20000から開始し、必要に応じて減らします。例:

    split -l 20000 filter-repo/commit-map filter-repo/commit-map-
  5. クリーンアップ開始を選択します。

クリーンアップが完了すると、GitLabは再計算されたリポジトリサイズを含むメール通知を送信します。

リポジトリからデータを削除する

リポジトリから機密情報または機密データを削除するには、次のいずれかの方法を使用します:

  • ファイルを完全に削除するには、blobを削除します。
  • ファイルを保持し、機密テキストを置換テキスト***REMOVED***で置き換えるには、テキストを削除するを使用します。

blobを消去する

Gitバイナリラージオブジェクト(blob)は、メタデータなしでファイルの内容を格納します。各blobには、リポジトリ内のファイルの特定のバージョンを表す一意のSHAハッシュがあります。

このメソッドを使用して、機密情報または秘密情報を含むblobを完全に消去します。

このプロセス:

  • Gitの履歴を書き換えます。
  • コミット署名をドロップします。
  • 開いているマージリクエストがマージに失敗し、手動でのリベースが必要になる場合があります。
  • 古いコミットSHAを参照するパイプラインが中断する可能性があります。
  • 古いコミット履歴に基づいた履歴taggingとブランチに影響を与える可能性があります。
  • ローカルリポジトリの再クローンが必要です。
  • 元に戻すことはできません。

文字列を置換文字列***REMOVED***で置き換えることもできます。詳細については、リポジトリからテキストを削除するを参照してください。

前提条件:

  • プロジェクトのオーナーロールが必要です。
  • 削除するオブジェクトIDのリスト
  • プロジェクトは以下であってはなりません。
    • パブリックアップストリームプロジェクトのフォーク。
    • ダウンストリームフォークを含むパブリックアップストリームプロジェクト。

blobの削除を確実に行うには、プロセス中にリポジトリへのアクセスを一時的に制限することを検討してください。blobの消去中に新しいコミットがプッシュされると、操作が失敗する可能性があります。

リポジトリからblobを消去するには:

  1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
  2. 設定 > リポジトリを選択します。
  3. リポジトリの保守を展開します。
  4. blobを消去するを選択します。
  5. 消去するblob IDのリストを入力します。各IDは独自の行に入力します。
  6. blobを消去するを選択します。
  7. 確認ダイアログで、プロジェクトパスを入力します。
  8. はい、blobを消去しますを選択します。
  9. blobの削除が完了するまで待ってから続行します:
    • Eメール通知が有効な場合は、リポジトリの履歴の書き換えが完了したことを示すメールを受信するまでお待ちください。
    • メール通知が有効になっていない場合は、少なくとも5分間待ちます。
  10. 左側のサイドバーで、設定 > 一般を選択します。
  11. 詳細設定というラベルが付いたセクションを展開します。
  12. ハウスキーピングを実行を選択します。操作が完了するまで、少なくとも30分待ちます。
  13. 同じ設定 > 一般 > 高度な設定セクションで、到達不能オブジェクトを排除するを選択します。この操作が完了するまで約5〜10分かかります。

機密情報を含むプロジェクトがフォークした場合、ハウスキーピングタスクはこのプロセスを完了しなくても成功する可能性があります。ハウスキーピングは、フォークされたデータを含む特別なオブジェクトプールリポジトリの整合性を保持する必要があります。サポートが必要な場合は、GitLabサポートにお問い合わせください。

オブジェクトIDのリストを取得する

blobを消去するには、消去するオブジェクトのリストが必要です。これらのIDを取得するには、ls-treeコマンドまたはリポジトリツリーAPIエンドポイントを一覧表示を使用します。次の手順では、ls-treeコマンドを使用します。

前提条件:

  • リポジトリをローカルマシンに複製する必要があります。

特定のコミットまたはブランチにあるblobのリストをサイズでソートして取得するには:

  1. ターミナルを開き、リポジトリディレクトリに移動します。

  2. 次のコマンドを実行します:

    git ls-tree -r -t --long --full-name <COMMIT/BRANCH> | sort -nk 4

    出力例:

    100644 blob 8150ee86f923548d376459b29afecbe8495514e9  133508 doc/howto/img/remote-development-new-workspace-button.png
    100644 blob cde4360b3d3ee4f4c04c998d43cfaaf586f09740  214231 doc/howto/img/dependency_proxy_macos_config_new.png
    100644 blob 2ad0e839a709e73a6174e78321e87021b20be445  216452 doc/howto/img/gdk-in-gitpod.jpg
    100644 blob 115dd03fc0828a9011f012abbc58746f7c587a05  242304 doc/howto/img/gitpod-button-repository.jpg
    100644 blob c41ebb321a6a99f68ee6c353dd0ed29f52c1dc80  491158 doc/howto/img/dependency_proxy_macos_config.png

    出力の3番目の列は、blobのオブジェクトIDです。例: 8150ee86f923548d376459b29afecbe8495514e9

リポジトリからテキストを削除する

誤ってコミットされた機密情報や社外秘の情報を完全に削除し、リポジトリの履歴からアクセスできないようにします。文字列のリストを***REMOVED***に置き換えます。

この操作は元に戻せません。履歴を書き換え、ハウスキーピングを実行すると、変更は永続的になります。

GitLabでファイルを削除すると、公開されたシークレットが削除されますが、次のことも行われます:

  • Gitの履歴を書き換えます。古いコミット履歴に基づく履歴タグとブランチが正しく機能しない場合があります。
  • 破壊的です。既存のローカルクローンは、更新されたリポジトリとの互換性がないため、再度クローンする必要があります。
  • 削除によってコンテンツが更新されるため、コミットハッシュを更新します。
  • 書き換えプロセス中にコミット署名を破棄します。
  • コミットハッシュに依存する次のような機能が破損します。
    • マージリクエストを開く。開いているマージリクエストはマージに失敗し、手動でのリベースが必要になる場合があります。
    • 以前のコミットにリンクする。404エラーが発生します。
  • 古いコミットSHAを参照するパイプラインが破損し、再設定が必要になる場合があります。

リポジトリの整合性を高めるために、代わりに次のことを行う必要があります。

このアプローチは次のことを可能にします。

  • 将来のシークレット漏洩を積極的に防止する。
  • セキュリティコンプライアンスを確保しながら、Gitの履歴を保持する。

詳細については、シークレットプッシュ保護を参照してください。

あるいは、リポジトリから特定のファイルを完全に削除するには、blobを削除を参照してください。

前提条件:

  • プロジェクトのオーナーロールが必要です。

リポジトリからテキストを削除するには:

  1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
  2. 設定 > リポジトリを選択します。
  3. リポジトリの保守を展開します。
  4. テキストを削除するを選択します。
  5. ドロワーで、削除するテキストを入力します。正規表現とグロブパターンが受け入れられます。
  6. 一致する文字列を削除を選択します。
  7. 確認ダイアログで、プロジェクトパスを入力します。
  8. はい、一致する文字列を削除しますを選択します。
  9. 左側のサイドバーで、設定 > 一般を選択します。
  10. 高度な設定を展開します。
  11. ハウスキーピングを実行を選択します。操作が完了するまで、少なくとも30分待ちます。
  12. 同じ設定 > 一般 > 高度な設定セクションで、到達不能オブジェクトを排除するを選択します。この操作が完了するまで約5〜10分かかります。

機密情報を含むプロジェクトがフォークした場合、ハウスキーピングタスクは、特別なオブジェクトプールリポジトリにフォークしたデータが含まれている整合性を維持するために、この削除するプロセスを完了できない可能性があります。サポートが必要な場合は、GitLabサポートにお問い合わせください。

トラブルシューティング

これらのセクションには、発生する可能性のある問題の解決策があります。

GUIに表示されるリポジトリの統計情報が正しくない

GitLabインターフェースに表示されるリポジトリサイズまたはコミット番号が、エクスポートされた.tar.gzまたはローカルリポジトリと異なる場合は、次のようにします。

  1. GitLab管理者に、Railsコンソールを使用して強制的に更新するように依頼してください。

  2. 管理者は次のコマンドを実行する必要があります。

    p = Project.find_by_full_path('<namespace>/<project>')
    p.statistics.refresh!
  3. プロジェクトの統計情報をクリアし、再計算をトリガーするには:

    p.repository.expire_all_method_caches
    UpdateProjectStatisticsWorker.perform_async(p.id, ["commit_count","repository_size","storage_size","lfs_objects_size","container_registry_size"])
  4. アーティファクトの総ストレージスペースを確認するには:

    builds_with_artifacts = p.builds.with_downloadable_artifacts.all
    
    artifact_storage = 0
    builds_with_artifacts.find_each do |build|
      artifact_storage += build.artifacts_size
    end
    
    puts "#{artifact_storage} bytes"

クリーンアップ後にスペースが解放されない

リポジトリのクリーンアッププロセスを完了したが、ストレージの使用量が変更されない場合:

  • 到達不能オブジェクトは、2週間の猶予期間リポジトリに残ることに注意してください。
  • これらのオブジェクトはエクスポートには含まれませんが、ファイルシステムスペースを占有します。
  • 2週間後、これらのオブジェクトは自動的に削除され、ストレージ使用量の統計が更新されます。
  • このプロセスを迅速化するには、管理者に「到達不能オブジェクトの削除」ハウスキーピングタスクの実行を依頼してください。

blobが消去されない

blobが正常に消去されると、GitLabはプロジェクトの監査ログにエントリを追加し、操作を開始した人にメール通知を送信します。

blobの消去が失敗した場合、GitLabは、操作を開始した人に件名が<project_name> | Project history rewrite failureのメール通知を送信します。メール本文には、完全なエラーメッセージが含まれています。

考えられるエラーと解決策:

  • validating object ID: invalid object ID: オブジェクトIDリストに構文エラーまたは不正なオブジェクトIDが含まれています。これを解決するには:
    1. オブジェクトIDリストを再生成します。
    2. blob消去手順を再実行します。
  • source repository checksum altered: このエラーは、blob消去プロセス中に誰かがコミットをプッシュすると発生します。これを解決するには:
    1. リポジトリへのすべてのプッシュを一時的にブロックします。
    2. blob消去手順を再実行します。
    3. プロセスが正常に完了したら、プッシュを再度有効にします。

リポジトリのサイズ制限に達した

リポジトリのサイズ制限に達した場合:

  • いくつかのデータを削除して、新しいコミットを作成してみてください。
  • うまくいかない場合は、一部のblobをGit LFSに移動するか、履歴から古い依存関係更新を削除することを検討してください。
  • それでも変更をプッシュできない場合は、GitLab管理者にお問い合わせいただき、一時的にプロジェクトの制限を引き上げてください
  • 最後の手段として、新しいプロジェクトを作成し、データを移行します。

新しいコミットでファイルを削除しても、以前のコミットとblobがまだ存在するため、リポジトリサイズはすぐには減りません。サイズを効果的に縮小するには、git filter-repoのようなツールを使用して、履歴を書き換える必要があります。