Gitのファイル制限（数とサイズ）はどのくらいですか？

誰かがファイルの数とファイルのサイズのGit制限を知っていますか？

Linus自身からのこのメッセージは、他のいくつかの制限に役立ちます。

[...] CVS、つまり、実際には、「一度に1つのファイル」モデルにほとんど方向付けされています。

これは、100万個のファイルを作成でき、そのうちのいくつかをチェックアウトできるという点で優れています。他の999,995個のファイルの影響も確認できません。

基本的に、Gitがリポジトリ全体を実際に見ているだけではありません。少し制限したとしても（つまり、一部だけを確認するか、履歴を少しだけ遡って）、gitは常にすべてを気にし、知識を持ち歩きます。

したがって、gitですべてを1つの巨大なリポジトリとして見るように強制すると、gitのスケーリングは非常に悪くなり ます。その部分は本当に修正可能だとは思いませんが、おそらく改善することができます。

そして、はい、「大きなファイル」の問題があります。巨大なファイルをどうすればいいのか本当にわかりません。私たちは彼らを吸います、私は知っています。

私の他の回答で詳細を参照してください。Gitの制限は、各リポジトリが「ファイルの一貫したセット」、つまり「すべてのシステム」自体を表す必要があることです（「リポジトリの一部」にタグを付けることはできません）。
システムが自律型（ただし相互依存型）のパーツで構成されている場合は、サブモジュールを使用する必要があります。

Talljoeの回答で示されているように、制限はシステム 1（多数のファイル）の場合がありますが、Gitの性質（SHA-1キーによって表されるデータの一貫性について）を理解していれば、真の「制限」を実現できますある用法 1：つまり、あなたは店にしようとしてはならないすべてのもの、あなたは常にすべてのバックを取得したり、タグに準備されていない限り、Gitのリポジトリに。一部の大規模プロジェクトでは、意味がありません。

gitの制限の詳細については、「大きなファイル
を使用したgit」（git-lfsについて言及しています。gitリポジトリ外に大きなファイルを保存するためのソリューションです。GitHub、2015年4月）

gitリポジトリを制限する3つの問題：

• 巨大なファイル（packfileのxdeltaはメモリのみにあり、大きなファイルには適していません）
• 膨大な数のファイル、つまり、ブロブごとに1つのファイル、およびgit gcが遅いため、一度に1つのパックファイルを生成します。
• huge packfiles、（巨大な）packfileからデータを取得するには非効率的なpackfileインデックス。

最近のスレッド（2015年2月）は、Gitリポジトリの制限要因を示しています。

中央サーバーからのいくつかの同時クローンにより、他のユーザーの他の同時操作の速度も低下しますか？

クローン作成時にサーバーにロックはないため、理論的にはクローン作成は他の操作に影響を与えません。ただし、複製では大量のメモリを使用できます（到達可能性ビットマップ機能をオンにしない限り、大量のCPUが必要です）。

「git pull」は遅くなりますか？

サーバー側を除外する場合、ツリーのサイズが主な要因ですが、25kファイルで十分です（linuxには48kファイルがあります）。

' git push'？

これは、リポジトリの履歴の深さや、ツリーの幅に影響されないので、早くする必要があります。

参照数はgit-pushとの両方に影響する可能性がありgit-pullます。
この分野では、ステファンは私よりもよく知っていると思います。

」git commit '？（これは、スローとして表示され、基準3） ' git status「？（参考文献3では見られませんが、再び遅くなります。）
（またgit-add）

繰り返しますが、あなたのツリーのサイズ。あなたのレポのサイズでは、あなたはそれを心配する必要はないと思います。

一部の操作は日常的ではないように見えるかもしれませんが、WebフロントエンドからGitLab / Stash / GitHubなどに頻繁に呼び出されると、ボトルネックになる可能性があります。（たとえば、 ' git branch --contains'は多数のブランチによってひどく悪影響を受けているようです。）

git-blame ファイルが頻繁に変更されると遅くなる可能性があります。

実際の制限はありません。すべての名前は160ビットの名前です。ファイルのサイズは64ビットの数値で表現できる必要があるため、実際の制限もありません。

ただし、実際的な制限はあります。8GBを超えるリポジトリに880,000を超えるファイルがあり、git gcには時間がかかります。作業ツリーはかなり大きいため、作業ディレクトリ全体を検査する操作にはかなり時間がかかります。ただし、このリポジトリはデータストレージにのみ使用されるため、それを処理する自動化ツールの集まりにすぎません。リポジトリから変更をプルすることは、同じデータをrsyncするよりもはるかに高速です。

%find . -type f | wc -l
791887
%time git add .
git add .  6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status  0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G     .
%cd .git
%du -sh .
7.9G    .

大きすぎるファイル（私の場合はGB、Cygwin、XP、3 GB RAM）を追加する場合は、これを期待してください。

致命的：メモリ不足のため、mallocが失敗しました

詳細はこちら

Update 3/2/11：Windows 7 x64でTortoise Gitを使用して同様に見た。大量のメモリが使用され、システムの応答が非常に遅い。

2012年2月に戻って、巨大なテストリポジトリでGitをテストするFacebookソフトウェアエンジニアであるJoshua RedstoneからのGitメーリングリストに非常に興味深いスレッドがありました。

テストリポジトリには、400万のコミット、線形履歴、約130万のファイルがあります。

実行されたテストは、そのようなレポジトリではGitが使用できないことを示しています（コールド操作が数分間続く）が、これは将来変更される可能性があります。基本的に、パフォーマンスはstat()カーネルFSモジュールへの呼び出し回数によって不利になるため、リポジトリ内のファイル数とFSキャッシュ効率に依存します。詳細については、この要旨も参照してください。

2018-04-20現在、Git for Windowsには、その特定の実装を使用してファイルサイズを最大4GBに効果的に制限するバグがあります（このバグはlfsにも伝播します）。

それはあなたの意味が何であるかに依存します。実用的なサイズ制限があります（大きなファイルがたくさんある場合、退屈に遅くなる可能性があります）。ファイルが多い場合、スキャンも遅くなる可能性があります。

ただし、モデルに固有の制限はありません。あなたは確かにそれを不十分に使用し、惨めになることができます。

大きなファイルのコミットをリポジトリの一部として回避するのは良いことだと思います（たとえば、データベースダンプは他の場所に配置した方がいいかもしれません）が、リポジトリ内のカーネルのサイズを考慮すると、おそらく快適に動作することが期待できます。サイズは小さく、それよりも複雑ではありません。

私のリポジトリには、個別のJSONフラグメントとして大量のデータが保存されています。いくつかのディレクトリの下に約75,000個のファイルがあり、パフォーマンスに悪影響を与えることはありません。

最初にそれらをチェックすることは、明らかに、少し時間がかかりました。

私はこれが膨大な数のファイル（350k +）をリポジトリに保存しようとしているのを発見しました。はい、保存します。笑う。

$ time git add . 
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total

以下のBitbucket ドキュメントからの抜粋は非常に興味深いものです。

DVCSリポジトリのクローン作成、プッシュを操作する場合、リポジトリ全体とそのすべての履歴を操作します。実際には、リポジトリが500MBを超えると、問題が発生する可能性があります。

... Bitbucketの顧客の94％が500MB未満のリポジトリを持っています。LinuxカーネルとAndroidはどちらも900MB未満です。

そのページで推奨される解決策は、プロジェクトを小さなチャンクに分割することです。

gitには、リポジトリに4G（32ビット）の制限があります。

http://code.google.com/p/support/wiki/GitFAQ