Gestion des fichiers volumineux binaires avec Git

https://stackoverflow.com/questions/540535

22-08-2019
|

Question

Je cherche des avis sur la façon de gérer de gros fichiers binaires sur lesquels mon code source (application Web) dépend. Nous discutons actuellement plusieurs alternatives:

Copiez les fichiers binaires manuellement.
- Pro. Je ne sais pas
- Contra: Je suis tout à fait contre cela, car il augmente la probabilité d'erreurs lors de la mise en place d'un nouveau site / migration de l'ancien. Édifie un autre obstacle à prendre.
les gérer avec Git .
- Pro: supprime la possibilité de 'oublier' pour copier un fichier important
- Contra: gonflerait le dépôt et diminue la flexibilité pour gérer la base de code et checkouts, clones, etc. prendra un certain temps
Des répertoires distincts.
- Pro. Analysant / clonage du code source est rapide que jamais, et les images sont correctement archivées dans leur propre référentiel
- Contra: Supprime le simpleness d'avoir la seule et unique dépôt Git sur le projet. Il introduit sûrement d'autres choses que je ne l'ai pas pensé.

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

Aussi: Est-ce que quelqu'un a l'expérience avec plusieurs référentiels Git et de les gérer dans un projet

Les fichiers sont des images pour un programme qui génère des fichiers PDF avec les fichiers qu'il contient. Les fichiers ne changeront pas très souvent (comme les années), mais ils sont très pertinents pour un programme. Le programme ne fonctionnera pas sans les fichiers.

La solution

Si le programme ne fonctionnera pas sans les fichiers, il semble que les scindant en une prise en pension séparée est une mauvaise idée. Nous avons de grandes suites de test que nous rompons dans une pension séparée, mais ceux-ci sont vraiment des fichiers « auxiliaires ».

Cependant, vous pourriez être en mesure de gérer les fichiers dans un repo séparé puis utilisez git-submodule pour les tirer dans votre projet d'une manière saine d'esprit. Donc, vous auriez encore l'histoire complète de toutes vos sources, mais, si je comprends bien, vous auriez seulement avoir une révision pertinente de vos images sous-module. L'installation de git-submodule devrait vous aider à garder la version correcte du code conforme à la version correcte des images.

Voici une bonne introduction à sous-modules de Git livre.

Autres conseils

J'ai découvert git-annexe récemment que je trouve génial. Il a été conçu pour gérer efficacement des fichiers volumineux. Je l'utilise pour ma photo / collections de musique (etc.). Le développement de l'annexe-git est très actif. Le contenu des fichiers peut être retiré du dépôt Git, seule la hiérarchie de l'arborescence est suivi par Git (par des liens symboliques). Cependant, pour obtenir le contenu du fichier, une deuxième étape est nécessaire après pousser / tirer, par exemple:.

$ 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 beaucoup de commandes disponibles, et il y a une grande documentation sur le site. Un forfait est disponible sur Debian .

Une autre solution, depuis Avril 2015 est Git Grand stockage de fichiers (EPA) (par GitHub).

Il utilise git-LFS (voir < a href = "https://git-lfs.github.com/" rel = "noreferrer"> git-lfs.github.com ) et testé avec un serveur supportant: LFS-test-serveur :
Vous pouvez stocker les métadonnées dans le git, et le grand fichier ailleurs.

Jetez un oeil à git BUP qui est une extension Git pour stocker intelligemment les grands binaires dans une Git dépôt.

Vous voudriez avoir comme un sous-module, mais vous ne serez pas à vous soucier du dépôt devient difficile à manipuler. L'un de leurs échantillons de cas d'utilisation est le stockage des images VM dans Git.

Je n'ai pas vraiment vu de meilleurs taux de compression, mais mes dépôts n'ont pas vraiment binaires grand en eux.

Votre kilométrage peut varier.

Vous pouvez également utiliser git-graisse . J'aime que cela ne dépend que de stock Python et rsync . Il prend également en charge le flux de travail de Git habituelle, avec les commandes auto explicatives suivantes:

git fat init
git fat push
git fat pull

En outre, vous devez vérifier dans un fichier .gitfat dans votre référentiel et modifier vos .gitattributes pour spécifier les extensions de fichiers que vous souhaitez git fat gérer.

Vous ajoutez un fichier binaire en utilisant la git add normale, ce qui appelle à son tour git fat en fonction de vos règles gitattributes.

Enfin, il a l'avantage que l'endroit où vos binaires sont stockés peuvent être partagés entre les référentiels et les utilisateurs et soutient tout ce rsync fait.

MISE À JOUR: Ne pas utiliser en gras git si vous utilisez un pont Git-SVN. Il finira par supprimer les fichiers binaires à partir de votre dépôt Subversion. Toutefois, si vous utilisez un dépôt Git pur, il fonctionne à merveille.

J'utiliser (comme Pat sous-modules Notz) ou deux référentiels distincts. Si vous modifiez vos fichiers binaires trop souvent, alors je voudrais essayer de minimiser l'impact de l'énorme dépôt de nettoyage de l'histoire:

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

I utilisé un lecteur de disque dur externe avec le principal dépôt Git, et je cloné dans chaque ordinateur. , J'ai commencé ensuite de les classer de la manière habituelle (pousser, tirer, fusionner ... supprimer et renommer plusieurs fois).

A la fin, je n'avais ~ 6 Go de fichiers MP3 et ~ 83 Go dans le répertoire .git. Je git-write-tree et git-commit-tree pour créer un nouveau commit, sans commettre ancêtres, et a commencé une nouvelle branche pointant vers ce commettras. La branche pour cette seule a montré "git log" un commit.

Alors, je supprimé la vieille branche, n'a retenu que la nouvelle branche, radiée les ref-logs, et exécuter « pruneau git »: après cela, mes dossiers .git pondérés seulement ~ 6 Go ...

Vous pouvez « purge » l'énorme dépôt de temps à autre de la même manière: Votre « clone git » 's sera plus rapide

À mon avis, si vous êtes susceptible de modifier souvent les gros fichiers, ou si vous avez l'intention de faire beaucoup de git clone ou git checkout, alors vous devriez sérieusement envisager d'utiliser un autre dépôt Git (ou peut-être une autre façon d'accéder à ces fichiers ).

Mais si vous travaillez comme nous le faisons, et si vos fichiers binaires ne sont pas souvent modifiés, le premier clone / caisse sera longue, mais après qu'il devrait être aussi rapide que vous voulez (en considérant vos utilisateurs de continuer à utiliser la première dépôt cloné ils avaient).

La solution que je voudrais proposer est basée sur les branches orphelines et une légère utilisation abusive du mécanisme d'étiquette, désormais appelés * Orphelin Mots clés binaire de stockage (OTABS)

TL; DR 01/12/2017 Si vous pouvez utiliser l'EPA de GitHub ou d'une autre 3ème partie, par tout ce que vous devriez signifie. Si vous ne pouvez pas, alors lisez la suite. Soyez averti, cette solution est un hack et doit être traitée comme telle.

propriétés de Souhaitable OTABS

il est git pur et GIT Solution - il fait le travail sans logiciel 3ème partie (comme git-annexe) ou de l'infrastructure 3e partie (comme EPA) de GitHub.
il stocke les fichiers binaires efficacement , à savoir qu'il ne ballonnement pas l'histoire de votre dépôt.
git pull et git fetch, y compris git fetch --all sont encore bande passante efficace , à savoir tous les grands binaires sont tirés de la télécommande par défaut.
il fonctionne sur de Windows .
il stocke tout dans un simple dépôt git .
il permet suppression des binaires obsolètes (contrairement BUP).

propriétés indésirables de OTABS

il est git clone potentiellement inefficace (mais pas nécessairement, en fonction de votre utilisation). Si vous déployez cette solution, vous pourriez avoir à conseiller vos collègues à utiliser git clone -b master --single-branch <url> au lieu de git clone. Ce clone est parce que git par défaut littéralement clones ensemble dépôt, y compris les choses que vous ne voudriez pas normalement perdre votre bande passante, comme commits non référencées. Tiré de SO 4811434 .
il rend la bande passante git fetch <remote> --tags inefficace, mais pas nécessairement le stockage inefficace. Vous pouvez peut toujours conseiller à vos collègues de ne pas l'utiliser.
vous devrez utiliser périodiquement un truc git gc pour nettoyer votre dépôt de fichiers que vous ne voulez pas plus.
il est pas aussi efficace que BUP ou git-bigfiles . Mais il est respectivement plus approprié pour ce que vous essayez de faire et plus impromptu. Vous êtes susceptible d'avoir des ennuis avec des centaines de milliers de petits fichiers ou avec des fichiers à portée de giga-octets, mais lisez la suite pour des solutions de contournement.

Ajout des fichiers binaires

Avant de commencer, assurez-vous que vous avez commis tous vos changements, votre arbre de travail est à jour et votre index ne contient pas de modifications non validées. Il pourrait être une bonne idée de pousser toutes vos branches locales à votre télécommande (GitHub, etc.) au cas où une catastrophe devrait se produire.

Créer une nouvelle branche orpheline. git checkout --orphan binaryStuff fera l'affaire. Cela produit une branche qui est tout à fait déconnecté de toute autre branche, et le premier que vous allez faire engager dans cette branche aura pas de parent, ce qui en fera une validation racine.
Nettoyez votre index à l'aide git rm --cached * .gitignore.
Prenez une grande respiration et supprimer l'arbre de travail entier à l'aide rm -fr * .gitignore. répertoire .git interne restera intacte, parce que le caractère générique * ne correspond pas.
Copier dans votre VeryBigBinary.exe ou votre VeryHeavyDirectory /.
Ajoutez && commettre.
Maintenant, il devient difficile - si vous le poussez dans la télécommande comme une branche tous vos développeurs télécharger la prochaine fois qu'ils invoquent git fetch obstruer leur connexion. Vous pouvez éviter cela en poussant une étiquette au lieu d'une branche. Cela peut avoir un impact encore la bande passante et le stockage système de fichiers de votre collègue si elles ont l'habitude de taper git fetch <remote> --tags, mais lisez la suite pour une solution de contournement. Allez-y et git tag 1.0.0bin
Poussez votre balise orphelin git push <remote> 1.0.0bin.
Juste pour que vous ne poussez votre branche binaire par accident, vous pouvez le supprimer git branch -D binaryStuff. Votre engagement ne sera pas marqué pour la collecte des ordures, car une étiquette orpheline pointant sur elle 1.0.0bin suffit de le maintenir en vie.

Vérifier le fichier binaire

Comment puis-je (ou mes collègues) obtenir le VeryBigBinary.exe vérifié dans l'arbre de travail actuel? Si votre branche de travail actuelle est par exemple maîtriser, vous pouvez simplement git checkout 1.0.0bin -- VeryBigBinary.exe.
Cela échouera si vous ne possédez pas l'étiquette orpheline 1.0.0bin téléchargée, dans ce cas, vous devrez au préalable git fetch <remote> 1.0.0bin.
Vous pouvez ajouter le VeryBigBinary.exe dans la .gitignore de votre maître, de sorte que personne ne sur votre équipe pollue l'histoire principale du projet avec le binaire par accident.

complètement Suppression du fichier binaire

Si vous décidez de purger complètement VeryBigBinary.exe de votre dépôt local, votre dépôt à distance et les dépôts de votre collègue, vous pouvez simplement:

Supprimer la balise orphelin sur la git push <remote> :refs/tags/1.0.0bin à distance
Supprimer la balise orphelin localement (supprime tous les autres balises non référencées) git tag -l | xargs git tag -d && git fetch --tags. Tiré de SO 1841341 avec une légère modification.
Utilisez un truc git gc supprimer votre entreprise commettras localement non référencé. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@". Il supprime également tous les autres commits non référencées. Tiré de SO 1904860
Si possible, répétez l'affaire git gc sur la télécommande. Il est possible que si vous êtes auto-hébergement de votre dépôt et pourrait ne pas être possible avec certains fournisseurs de git, comme github ou dans certains environnements d'entreprise. Si vous hébergez avec un fournisseur qui ne laisse vous donne pas accès ssh à la télécommande juste être. Il est possible que l'infrastructure de votre fournisseur nettoiera votre engagement dans leur non référencé propre temps doux. Si vous êtes dans un environnement d'entreprise, vous pouvez conseiller votre IT pour exécuter une poubelle tâche Cron collecte une fois votre distance par semaine. Qu'ils le fassent ou ne seront pas avoir d'impact sur votre équipe en termes de bande passante et de stockage, aussi longtemps que vous conseillez vos collègues de toujours git clone -b master --single-branch <url> au lieu de git clone.
Tous vos collègues qui veulent se débarrasser des étiquettes orphelines obsolètes doivent seulement appliquer les étapes 2-3.
Vous pouvez ensuite répéter les étapes 1-8 de Ajout des fichiers binaires pour créer un nouveau 2.0.0bin tag orphelin. Si vous êtes inquiet au sujet de vos collègues, vous pouvez taper git fetch <remote> --tags le nom fait encore 1.0.0bin. Cela fera en sorte que la prochaine fois qu'ils vont chercher toutes les balises l'ancien 1.0.0bin sera marqué et sans référence pour la collecte ultérieure des déchets (en utilisant l'étape 3). Lorsque vous essayez d'écraser une étiquette sur la télécommande, vous devez utiliser -f comme ceci: git push -f <remote> <tagname>

postface

OTABS ne touche pas votre maître ou tout autre code source / branches de développement. Les comi hash, toute l'histoire, et la petite taille de ces branches n'est pas affectée. Si vous avez déjà pléthorique votre historique de code source avec les fichiers binaires, vous devrez nettoyer comme une feuille de travail. Ce script pourrait être utile.
Confirmé pour fonctionner sur Windows avec BASH git.
Il est une bonne idée d'appliquer un ensemble de trics standards pour rendre le stockage des fichiers binaires plus efficace. fonctionnement fréquent de git gc (sans arguments supplémentaires) fait optimize git sous-jacente stockage de vos fichiers en utilisant deltas binaires. Toutefois, si vos fichiers sont peu susceptibles de rester similaires de s'engager à vous engager pouvez désactiver les deltas binaires tout à fait. De plus, parce qu'il n'a pas de sens pour compresser déjà compressés ou les fichiers cryptés, comme .zip, .jpg ou .crypt, git vous permet de désactiver la compression du stockage sous-jacent. Malheureusement, il est un cadre tout ou rien qui affecte votre code source ainsi.
Vous pouvez le script des parties de OTABS pour permettre une utilisation plus rapide. En particulier, les scripts les étapes 2-3 de complètement Suppression de fichiers binaires dans un crochet git update pourrait donner une sémantique convaincante mais peut-être dangereux pour git fetch ( « chercher et supprimer tout ce qui est à jour »).
Vous pouvez sauter l'étape 4 Supprimer complètement les fichiers binaires pour garder un historique complet de tous les changements binaires sur la télécommande au coût du dépôt central ballonnement. dépôts locaux restent maigres au fil du temps.
Dans le monde Java, il est possible de combiner cette solution avec maven --offline pour créer une version hors ligne reproductible stockée entièrement dans votre contrôle de version (il est plus facile avec Maven qu'avec gradle). Dans le monde golang il est possible de tirer parti de cette solution pour gérer votre GOPATH au lieu de go get. Dans le monde de python, il est possible de combiner cela avec virtualenv pour produire un environnement de développement autonome sans compter sur les serveurs PyPI pour chaque construire à partir de zéro.
Si vos fichiers binaires changent très souvent, comme des objets de construction, il pourrait être une bonne idée de scénario une solution qui stocke 5 versions les plus récentes des artefacts dans les balises orphelines monday_bin, tuesday_bin, ..., friday_bin et aussi une étiquette d'orphelin pour chaque version 1.7.8bin 2.0.0bin, etc. Vous pouvez faire pivoter l'weekday_bin et supprimer les anciens binaires par jour. De cette façon, vous obtenez le meilleur des deux mondes: vous gardez les toute l'histoire de votre code source, mais seulement la correspondant historique de vos dépendances binaires. Il est également très facile d'obtenir les fichiers binaires pour un tag donné sans obtenir l'ensemble du code source avec toute son histoire. git init && git remote add <name> <url> && git fetch <name> <tag> devrait le faire pour vous

SVN semble gérer deltas binaires plus efficacement que Git.

Je devais décider d'un système de versionnage pour la documentation (fichiers JPEG, les fichiers PDF et des fichiers .odt). Je viens de tester l'ajout d'un fichier JPEG et en le tournant de 90 degrés quatre fois (pour vérifier l'efficacité des deltas binaires). Le dépôt de Git a augmenté de 400%. Le dépôt de SVN n'a augmenté que de 11%.

Il semble donc que SVN est beaucoup plus efficace avec les fichiers binaires.

Donc, mon choix est Git pour le code source et SVN pour les fichiers binaires comme la documentation.

git clone --filter de Git 2.19 + clones peu profonds

Cette nouvelle option pourrait éventuellement devenir la solution finale au problème de fichier binaire, si les devs Git et GitHub et le rendre utilisateur assez convivial (sans doute qu'ils ont pas encore atteint pour sous-modules, par exemple).

Il permet de chercher en réalité uniquement les fichiers et les répertoires que vous souhaitez pour le serveur, et a été introduit en même temps avec une extension de protocole à distance.

Avec cela, nous pourrions d'abord faire un clone peu profond, puis automatiser qui blobs chercher avec le système de construction pour chaque type de construction.

Il y a même déjà un --filter=blob:limit<size> qui permet de limiter la taille maximale de blob chercher.

J'ai fourni un exemple détaillé minimal de la façon dont la fonction ressemble à: Comment cloner un sous-répertoire uniquement d'un dépôt Git?

Je cherche des avis sur la façon de gérer de gros fichiers binaires sur lesquels mon code source (application Web) dépend. Quelles sont vos expériences / réflexions sur ce sujet?

J'ai personnellement courir dans des échecs de synchronisation avec Git avec certains de mes hôtes nuage une fois mes applications web de données binaires entaillés au-dessus de la barre des 3 Go . Je considérais BFT repo Cleaner à l'époque, mais je me sentais comme un hack. Depuis, j'ai commencé juste garder des fichiers en dehors du champ Git, tirant parti de la place outils construits à cet effet comme Amazon S3 pour la gestion des fichiers, et versioning back-up.

Quelqu'un at-il une expérience avec plusieurs référentiels Git et de les gérer dans un projet?

Oui. thèmes Hugo sont principalement gérées de cette façon. Il est un peu kudgy, mais il fait le travail.

Ma suggestion est de choisir le bon outil pour le travail . Si elle est pour une entreprise et vous gérez votre ligne de code sur GitHub payer l'argent et utiliser Git-EPA. Sinon, vous pouvez explorer les options plus créatives telles que blockchain.

D'autres options à considérer Minio et s3cmd .

Jetez un oeil à camlistore . Il est pas vraiment basé-Git, mais je trouve qu'il est plus approprié pour ce que vous avez à faire.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow