Gérer les gros fichiers binaires avec Git

Question

Je cherche des avis sur la manière de traiter les gros fichiers binaires dont dépend mon code source (application web). Nous sommes en train de discuter de plusieurs alternatives :

1. Copiez les fichiers binaires à la main.
   • Pro : Pas sûr.
   • Contre : Je suis fortement contre, car cela augmente la probabilité d'erreurs lors de la mise en place d'un nouveau site/migration de l'ancien. Cela crée un obstacle supplémentaire à franchir.
2. Gérez-les tous avec Git .
   • Pro : Supprime la possibilité d'oublier de copier un fichier important.
   • Contra : Bloque le dépôt et diminue la flexibilité pour gérer la base de code et les checkouts, clones, etc. prendront un certain temps.
3. Dépôts séparés.
   • Pro : L'extraction/le clonage du code source est plus rapide que jamais, et les images sont correctement archivées dans leur propre dépôt.
   • Contra : Enlève la simplicité d'avoir le seul et unique Dépôt Git sur le projet. Cela introduit sûrement d'autres choses auxquelles je n'ai pas pensé.

Quelles sont vos expériences/réflexions à ce sujet ?

Aussi : Quelqu'un a-t-il de l'expérience avec plusieurs dépôts Git et leur gestion dans un seul projet ?

Les fichiers sont des images pour un programme qui génère des PDF avec ces fichiers. Les fichiers ne changent pas très souvent (comme dans les années), mais ils sont très importants pour un programme. Le programme ne fonctionnera pas sans les fichiers.

Answer 1

J'ai découvert git-annex récemment, ce que je trouve génial. Il a été conçu pour gérer efficacement les gros fichiers. Je l'utilise pour mes collections de photos/musiques (etc.). Le développement de git-annex est très actif. Le contenu des fichiers peut être supprimé du dépôt Git, seule la hiérarchie de l'arbre est suivie par Git (grâce aux liens symboliques). Cependant, pour obtenir le contenu du fichier, une deuxième étape est nécessaire après le pulling/pushing, par ex :

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

Il y a de nombreuses commandes disponibles, et une excellente documentation sur le site web. Un paquet est disponible sur Debian .

Answer 2

Si le programme ne fonctionne pas sans les fichiers, il semble que les séparer dans un dépôt séparé soit une mauvaise idée. Nous avons de grandes suites de tests que nous séparons dans un dépôt séparé, mais ce sont vraiment des fichiers "auxiliaires".

Cependant, il est possible de gérer les fichiers dans un dépôt séparé, puis d'utiliser la fonction git-submodule pour les attirer dans votre projet d'une manière saine. Ainsi, vous auriez toujours l'historique complet de toutes vos sources mais, si je comprends bien, vous n'auriez que la seule révision pertinente de votre sous-module images. Le site git-submodule devrait vous aider à garder la bonne version du code en ligne avec la bonne version des images.

Voici un bon introduction aux submodules de Git Book.

Answer 3

Jetez un coup d'œil à git bup qui est une extension de Git permettant de stocker intelligemment des binaires volumineux dans un dépôt Git.

Vous voudrez l'avoir en tant que sous-module, mais vous n'aurez pas à vous inquiéter que le dépôt devienne difficile à gérer. L'un de leurs exemples d'utilisation est le stockage d'images de machines virtuelles dans Git.

Je n'ai pas vraiment constaté de meilleurs taux de compression, mais mes dépôts ne contiennent pas de binaires vraiment volumineux.

Votre kilométrage peut varier.

Answer 4

Vous pouvez également utiliser git-fat . J'aime que cela ne dépende que du stock de Python et rsync . Il prend également en charge le flux de travail habituel de Git, avec les commandes explicites suivantes :

git fat init
git fat push
git fat pull

En outre, vous devez enregistrer un fichier .gitfat dans votre dépôt et modifier votre fichier .gitattributes afin de spécifier les extensions de fichier que vous souhaitez. git fat à gérer.

Vous ajoutez un binaire en utilisant la méthode normale git add qui, à son tour, invoque git fat en fonction de vos règles de gitattributs.

Enfin, il présente l'avantage que l'emplacement où sont stockés vos binaires peut être partagé entre les dépôts et les utilisateurs et qu'il prend en charge tout ce qui est nécessaire. rsync fait.

MISE À JOUR : N'utilisez pas git-fat si vous utilisez un pont Git-SVN. Il finira par supprimer les fichiers binaires de votre dépôt Subversion. Cependant, si vous utilisez un dépôt Git pur, cela fonctionne parfaitement.

Answer 5

J'utiliserais des submodules (comme Pat Notz) ou deux dépôts distincts. Si vous modifiez vos fichiers binaires trop souvent, alors j'essaierais de minimiser l'impact de l'énorme dépôt qui nettoie l'historique :

J'ai eu un problème très similaire il y a plusieurs mois : ~21 GB de fichiers MP3, non classés (mauvais noms, mauvais id3's, je ne sais pas si j'aime ce fichier MP3 ou pas...), et répliqués sur trois ordinateurs.

J'ai utilisé un disque dur externe avec le dépôt Git principal, et je l'ai cloné sur chaque ordinateur. Ensuite, j'ai commencé à les classer de la manière habituelle (en poussant, tirant, fusionnant... en supprimant et renommant plusieurs fois).

À la fin, je n'avais que 6 Go de fichiers MP3 et 83 Go dans le répertoire .git. J'ai utilisé git-write-tree et git-commit-tree pour créer un nouveau commit, sans ancêtres de commit, et a démarré une nouvelle branche pointant vers ce commit. Le "git log" de cette branche ne montre qu'un seul commit.

Ensuite, j'ai supprimé l'ancienne branche, gardé uniquement la nouvelle branche, supprimé les ref-logs, et lancé "git prune" : après cela, mes dossiers .git ne pesaient plus que ~6 Go...

Vous pourriez "purger" l'énorme dépôt de temps en temps de la même manière : Vos "clones git" seront plus rapides.