14

私は現在、大規模なリポジトリ (約 12 GB、各ブランチのサイズは 3 GB) に git を使用しています。このリポジトリには、多数のバイナリ ファイル (オーディオとイメージ) が含まれています。

問題は、クローンとプルに時間がかかることです。特に、「デルタの解決」ステップは非常に長くなる可能性があります。

この種の問題を解決する最善の方法は何ですか?

ここで .gitattributes のデルタ オプションを使用して説明されているように、デルタ圧縮を削除しようとしましたが、クローンの期間は改善されないようです。

前もって感謝します

ケビン

4

2 に答える 2

12

2015 年 4 月の更新: Git Large File Storage (LFS) (GitHub による)。

これはgit-lfs ( git-lfs.github.comを参照) を使用し、それをサポートするサーバーでテストされています: lfs-test-server :
メタデータは git リポジトリにのみ保存でき、大きなファイルは別の場所に保存できます

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb-8fc165e5ece4.gif


元の回答 (2012)

あまり変更されない大きなバイナリ ファイルの 1 つの解決策は、それらを別のリファレンス ( Nexus リポジトリなど) に格納し、必要なバージョンを宣言するテキスト ファイルのみをバージョン管理することです。
「アーティファクト リポジトリ」を使用することは、ソースリポジトリにバイナリ要素を保存するよりも簡単です (バージョンを比較し、ブランチ間でマージするために作成されたもので、上記のバイナリにはあまり役に立ちません)。

よりgit中心の他のソリューションはgit-annexです。

git-annexファイルの内容を git にチェックインすることなく、git でファイルを管理できます。
逆説的に思えるかもしれませんが、メモリ、時間、またはディスク容量の制限が原因で、git が現在簡単に処理できないサイズのファイルを処理する場合に便利です。

ただし、Windows には対応していません。

より一般的なソリューションはgit-mediaである可能性があります。これにより、Git 自体にメディアを保存することなく、大きなメディア ファイルで Git を使用することもできます。

最後に、最も簡単な解決策は、質問で述べたように、これらのバイナリを独自のgit サブモジュールに分離することです。これはあまり満足のいくものではなく、最初のクローンにはまだ時間がかかりますが、親リポジトリの次の更新は短くなります。

于 2012-10-12T09:23:33.457 に答える