Quelles sont les limites de fichiers dans Git (nombre et taille)?

Quelqu'un sait-il quelles sont les limites Git pour le nombre de fichiers et la taille des fichiers?

Ce message de Linus lui-même peut vous aider avec d'autres limites

[...] CVS, c'est-à-dire qu'il finit par être plutôt orienté vers un modèle "un fichier à la fois".

Ce qui est agréable dans ce que vous pouvez avoir un million de fichiers, et seulement vérifier certains d'entre eux - vous ne serez jamais même voir l'impact des autres fichiers 999,995.

Fondamentalement, Git ne regarde jamais moins que l'ensemble du dépôt. Même si vous limitez un peu les choses (c'est-à-dire vérifier juste une partie, ou faire remonter un peu l'historique), git finit toujours par se soucier de tout et transporter les connaissances.

Donc, git évolue vraiment mal si vous le forcez à tout regarder comme un énorme dépôt. Je ne pense pas que cette partie soit vraiment réparable, même si nous pouvons probablement l'améliorer.

Et oui, alors il y a les problèmes de «gros fichiers». Je ne sais vraiment pas quoi faire des gros fichiers. On les suce, je sais.

Voir plus dans mon autre réponse : la limite avec Git est que chaque référentiel doit représenter un " ensemble cohérent de fichiers ", le "tout système" en lui-même (vous ne pouvez pas taguer "partie d'un référentiel").
Si votre système est composé de parties autonomes (mais interdépendantes), vous devez utiliser des sous-modules .

Comme l'illustre la réponse de Talljoe , la limite peut être une limite système (grand nombre de fichiers), mais si vous comprenez la nature de Git (à propos de la cohérence des données représentée par ses clés SHA-1), vous réaliserez la vraie "limite" est une utilisation : c'est-à-dire que vous ne devriez pas essayer de tout stocker dans un dépôt Git, à moins que vous ne soyez prêt à toujours tout récupérer ou baliser. Pour certains grands projets, cela n'aurait aucun sens.

Pour un examen plus approfondi des limites de git, consultez « git avec de gros fichiers »
(qui mentionne git-lfs : une solution pour stocker des fichiers volumineux en dehors du dépôt git. GitHub, avril 2015)

Les trois problèmes qui limitent un dépôt git:

• fichiers énormes (le xdelta pour packfile est en mémoire uniquement, ce qui n'est pas bon avec les gros fichiers)
• un grand nombre de fichiers , ce qui signifie un fichier par objet blob, et ralentir git gc pour générer un fichier pack à la fois.
• d'énormes fichiers pack , avec un index packfile inefficace pour récupérer les données du (énorme) fichier pack.

Un fil de discussion plus récent (février 2015) illustre les facteurs limitants pour un dépôt Git :

Quelques clones simultanés à partir du serveur central ralentiront-ils également d'autres opérations simultanées pour d'autres utilisateurs?

Il n'y a pas de verrou sur le serveur lors du clonage, donc en théorie le clonage n'affecte pas les autres opérations. Le clonage peut cependant utiliser beaucoup de mémoire (et beaucoup de CPU à moins que vous n'activiez la fonction bitmap d'accessibilité, ce que vous devriez).

Est-ce que ' git pull' sera lent?

Si nous excluons le côté serveur, la taille de votre arbre est le facteur principal , mais vos fichiers de 25k devraient être bien (linux a 48k fichiers).

' git push'?

Celui-ci n'est pas affecté par la profondeur de l'historique de votre repo ou la largeur de votre arbre, donc cela devrait être rapide.

Ah le nombre de refs peut affecter à la fois git-pushet git-pull.
Je pense que Stefan sait mieux que moi dans ce domaine.

' git commit'? (Il est répertorié comme lent dans la référence 3. ) ' git status'? (Ralentissez à nouveau dans la référence 3 même si je ne le vois pas.)
(Aussi git-add)

Encore une fois, la taille de votre arbre. À la taille de votre repo, je ne pense pas que vous ayez à vous en soucier.

Certaines opérations peuvent ne pas sembler être quotidiennes, mais si elles sont fréquemment appelées par le front-end Web vers GitLab / Stash / GitHub, etc., elles peuvent devenir des goulots d'étranglement. (par exemple, « git branch --contains» semble terriblement affecté par un grand nombre de branches.)

git-blame peut être lent lorsqu'un fichier est beaucoup modifié.

Il n'y a pas de vraie limite - tout est nommé avec un nom de 160 bits. La taille du fichier doit être représentable dans un nombre de 64 bits donc pas de limite réelle non plus.

Il y a cependant une limite pratique. J'ai un référentiel d'environ 8 Go avec> 880 000 fichiers et git gc prend un certain temps. L'arbre de travail est assez volumineux, donc les opérations qui inspectent tout le répertoire de travail prennent un certain temps. Cependant, ce dépôt n'est utilisé que pour le stockage de données, ce n'est donc qu'un ensemble d'outils automatisés qui le gèrent. Extraire les modifications du référentiel est beaucoup, beaucoup plus rapide que de resynchroniser les mêmes données.

%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    .

Si vous ajoutez des fichiers trop volumineux (Go dans mon cas, Cygwin, XP, 3 Go de RAM), attendez-vous à cela.

fatal: mémoire insuffisante, échec de malloc

Plus de détails ici

Mise à jour 3/2/11: Saw similaire dans Windows 7 x64 avec Tortoise Git. Tonnes de mémoire utilisée, réponse du système très très lente.

En février 2012, il y avait un fil de discussion très intéressant sur la liste de diffusion Git de Joshua Redstone, un ingénieur logiciel de Facebook testant Git sur un énorme référentiel de test:

Le dépôt de test a 4 millions de commits, un historique linéaire et environ 1,3 million de fichiers.

Les tests qui ont été exécutés montrent que pour un tel dépôt, Git est inutilisable (opération à froid durant quelques minutes), mais cela peut changer dans le futur. Fondamentalement, les performances sont pénalisées par le nombre d' stat()appels au module FS du noyau, donc cela dépendra du nombre de fichiers dans le dépôt et de l'efficacité de la mise en cache FS. Voir également ce résumé pour une discussion plus approfondie.

Depuis le 20/04/2018, Git pour Windows a un bogue qui limite effectivement la taille du fichier à 4 Go maximum en utilisant cette implémentation particulière (ce bogue se propage également à lfs ).

Cela dépend de votre signification. Il existe des limites de taille pratiques (si vous avez beaucoup de gros fichiers, cela peut devenir ennuyeux). Si vous avez beaucoup de fichiers, les analyses peuvent également être lentes.

Cependant, il n'y a pas vraiment de limites inhérentes au modèle. Vous pouvez certainement l'utiliser mal et être misérable.

Je pense qu'il est bon d'essayer d'éviter les gros fichiers commits comme faisant partie du référentiel (par exemple, un vidage de base de données pourrait être mieux ailleurs), mais si l'on considère la taille du noyau dans son référentiel, vous pouvez probablement vous attendre à travailler confortablement avec quelque chose de plus petit et de moins complexe que cela.

J'ai une quantité généreuse de données stockées dans mon dépôt en tant que fragments JSON individuels. Il y a environ 75 000 fichiers dans quelques répertoires et cela ne nuit pas vraiment aux performances.

Les vérifier pour la première fois était, de toute évidence, un peu lent.

J'ai trouvé cela en essayant de stocker un nombre massif de fichiers (350k +) dans un repo. Oui, stocker. Des rires.

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

Les extraits suivants de la documentation Bitbucket sont assez intéressants.

Lorsque vous travaillez avec un clonage de référentiel DVCS, vous travaillez avec tout le référentiel et toute son histoire. En pratique, une fois que votre référentiel dépasse 500 Mo, vous pouvez commencer à voir des problèmes.

... 94% des clients Bitbucket ont des référentiels inférieurs à 500 Mo. Le noyau Linux et Android font moins de 900 Mo.

La solution recommandée sur cette page consiste à diviser votre projet en petits morceaux.

git a une limite 4G (32 bits) pour le repo.

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