git est très très lent

Question

Mon projet est de six mois et git est très très lent. Nous faisons le suivi de autour de de 30, qui sont des fichiers de taille de 5 MO à 50 MO. Ceux sont des fichiers binaires et de nous garder dans git. Je pense que ces fichiers font git lent.

Est-il un moyen de tuer tous les fichiers de taille > 5 MO à partir du référentiel. Je sais que je perdrais tous ces fichiers et qui est d'accord avec moi.

Idéalement, je voudrais une commande qui serait la liste de tous les gros fichiers ( > 5 MO) . Je peux voir la liste et puis je dis bon aller de l'avant et de supprimer ces fichiers et de les rendre git plus rapide.

Je dois mentionner que git est lent, non seulement sur ma machine, mais le déploiement de l'application sur l'environnement de test est en train de prendre environ 3 heures.

Ainsi, le correctif devrait être quelque chose qui va influer sur le serveur et pas seulement les utilisateurs du référentiel.

Answer 1

Avez-vous ramasser les ordures?

 git gc
 

Cela fait une différence de vitesse significative, même pour les petites pensions.

Answer 2

Explication

Git est vraiment bon à l'énorme histoires de petits fichiers de texte, parce qu'il peut les stocker et de leurs changements de manière efficace. Dans le même temps, git est très mauvais dans les fichiers binaires, et naïvement stocker des copies du fichier (par défaut, au moins). Le référentiel devient énorme, et puis ça devient lent, comme vous l'avez observé.

C'est un problème commun chez les DVCS est aggravé par le fait que vous téléchargez chaque version de chaque fichier ("l'ensemble du référentiel") chaque fois que vous clone. Le gars au Four travaillent sur un plugin pour traiter ces gros fichiers de plus en plus comme Subversion, qui ne télécharge que les versions historiques sur la demande.

Solution

Cette commande liste tous les fichiers dans le répertoire courant de taille >= 5 MO.

find . -size +5000000c 2>/dev/null -exec ls -l {} \;

Si vous souhaitez supprimer les fichiers de l'ensemble de l'histoire du référentiel, vous pouvez utiliser cette idée avec git filter-branch à la marche de l'histoire et de se débarrasser de toutes les traces de fichiers volumineux. Après cela, tous les nouveaux clones du référentiel sera plus légère. Si vous voulez maigre en place d'un référentiel sans clonage, vous trouverez des instructions sur la page de man (voir "Liste de vérification pour la réduction d'un Référentiel").

git filter-branch --index-filter \
    'find . -size +5000000c 2>/dev/null -exec git rm --cached --ignore-unmatch {} \;'

Un mot d'avertissement: cela permettra à votre référentiel incompatible avec d'autres clones, parce que les arbres et les indices de fichiers différents enregistré; vous ne serez pas en mesure de pousser ou de tirer de plus.

Answer 3

Ici est censuré de révision destiné à être moins négatif et inflammatoires:

Git est un bien connu de faiblesse quand il s'agit de fichiers qui ne sont pas, ligne par ligne, des fichiers texte. Il n'existe actuellement pas de solution, et l'absence de plan annoncé par le git de l'équipe à cette adresse. Il existe des solutions de contournement si votre projet est de petite taille, disons, 100 MO. Il existe des branches du projet git pour remédier à ce problème d'évolutivité, mais ces branches ne sont pas mûrs en ce moment. Certains autres systèmes de contrôle de révision n'ont pas ce problème spécifique. Vous devriez considérer ce problème comme étant l'un des nombreux facteurs au moment de décider de sélectionner git en tant que votre système de contrôle des révisions.

Answer 4

Il n'y a rien de précis sur des fichiers binaires et de la manière dont git est de la manipulation. Lorsque vous ajoutez un fichier à un dépôt git, un en-tête est ajouté et le fichier est compressé avec zlib et renommé après le hash SHA1. C'est exactement la même quel que soit le type de fichier. Il n'y a rien de compression zlib qui rend problématique pour les fichiers binaires.

Mais à quelques points (pousser, gc) Git commencer à regarder la possibilité de delta compresser le contenu. Si git de trouver des fichiers qui sont similaires (nom de fichier, etc) c'est de les mettre dans la RAM et de départ pour compresser ensemble. Si vous avez 100 dossiers et chacun d'entre eux arr dire 50mo il va essayer de mettre les 5GO dans la mémoire en même temps. Pour cela, vous devez ajouter un peu plus à faire fonctionner les choses. Votre ordinateur peut ne pas avoir cette quantité de RAM et il commence à échanger. Le processus prend du temps.

Vous pouvez limiter la profondeur de la compression delta afin que le processus ne pas utiliser beaucoup de mémoire, mais le résultat est moins de compression efficace. (de base.bigFileThreshold, delta de l'attribut, pack.fenêtre, pack.profondeur, pack.windowMemory etc)

Il y a donc beaucoup de pense que vous pouvez faire pour rendre git fonctionne très bien avec de gros fichiers.

Answer 5

Une façon d'accélérer les choses est d'utiliser le drapeau --depth 1 . Voir la page de manuel pour plus de détails. Je ne suis pas un grand gourou, mais je crois que cela signifie de faire l'équivalent d'un p4 get ou d'un svn get , c'est-à-dire qu'il ne vous donne que les derniers fichiers au lieu de des révisions de tous les fichiers à travers tous les temps "qui est ce que git clone fait.