517 votes

Gestion des fichiers binaires volumineux avec git

Je suis à la recherche d'opinions de la façon de traiter de gros fichiers binaires sur lesquels mon code source (application web) est dépendante. Nous sommes en train de discuter de plusieurs alternatives:

  1. Copiez les fichiers binaires à la main.
    • Pro: Pas sûr.
    • Contra: je suis fortement contre cela, car cela augmente le risque d'erreurs lors de la mise en place d'un nouveau site/la migration de l'ancien. Construit un autre obstacle à prendre.
  2. Tous les gérer avec git.
    • Pro: Supprime la possibilité pour 'oublier' pour copier un fichier important
    • Contra: Gonfle le référentiel et diminue la souplesse nécessaire pour gérer le code de base et les extractions/clones/etc prendra un certain temps.
  3. Séparer les dépôts.
    • Pro: Vérification/clonage, le code source est rapide que jamais, et les images sont correctement archivés dans leur propre référentiel.
    • Contra: Supprime la simplicité d'avoir la seule et unique dépôt git sur le projet. Sûrement introduit quelques autres choses que je n'ai pas pensé.

Quelles sont vos expériences/pensées sur cette question?

Aussi: est-ce quelqu'un a de l'expérience avec de multiples dépôts git et de leur gestion dans un projet?

Mise à jour: 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(en années) mais qui sont très pertinents à un programme. Le programme ne fonctionnera pas sans les fichiers.

309voto

rafak Points 3310

J'ai découvert git-annex récemment que je trouve génial. Il a été conçu pour gérer de gros fichiers de manière efficace. Je l'utilise pour mes photos/musique (etc.) les collections. Le développement de git-annex est très active. Le contenu des fichiers peuvent être supprimés à partir du repo git, seule la hiérarchie de l'arbre est suivi par git (par le biais de liens symboliques). Cependant, pour obtenir le contenu du fichier, une deuxième étape est nécessaire après tirant/poussant, 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 ya une très bonne documentation sur le site web. Un package est disponible sur debian.

177voto

Pat Notz Points 46841

Si le programme ne fonctionnera pas sans les fichiers, il semble que le partage dans un autre repo est une mauvaise idée. Nous avons de grandes suites de tests qui nous casser dans un autre repo mais ceux qui sont vraiment "auxiliaire" de fichiers.

Cependant, vous pouvez être en mesure de gérer les fichiers dans un autre repo et ensuite utiliser git-submodule pour les ramener dans votre projet dans une façon saine. Donc, vous devez toujours avoir l'historique complet de toutes vos sources, mais, si je comprends bien, vous n'avez celui concernant la révision de vos images sous-module. L' git-submodule installation devrait vous aider à garder la bonne version du code en ligne avec la version correcte des images.

Voici une bonne introduction à submodules à partir de Git Livre.

30voto

sehe Points 123151
<p>Jetez un oeil à <a href="https://github.com/apenwarr/bup">git bup</a> qui est une extension de git pour stocker des gros fichiers binaires intelligemment dans un repo git.</p> <p>Vous voudriez avoir comme un sous-module, mais vous n’aurez pas à vous soucier de la repo devient difficile à gérer. Un des cas d’utilisation de leur échantillon est de stocker images VM dans git.</p> <p>Je n’ai pas réellement vu les meilleurs taux de compression, mais mon repos n’ont pas vraiment de gros fichiers binaires en eux.</p> <p>YMMV</p>

27voto

C.. Points 10739

Vous pouvez également utiliser git en gras. Ce que j'aime c'est qu'il ne dépend que des actions python et rsync. Il prend également en charge l'habitude de git, avec les explications des commandes:

git fat init
git fat push
git fat pull

En outre, vous devez vérifier dans un .gitfat de fichier dans votre repo et modifier vos .gitattributes pour spécifier les extensions de fichier que vous souhaitez git graisse à gérer.

Vous ajoutez un fichier binaire à l'aide de la normale git add, qui à son tour appelle git grasse en fonction de votre gitattributes règles.

Enfin, il a l'avantage que l'endroit où vos fichiers binaires sont en fait stockées peuvent être partagées à travers les référentiels et les utilisateurs et prend en charge tout ce rsync.

Mise à JOUR: Ne pas utiliser git en gras si vous utilisez un git-svn pont. Il supprime les fichiers binaires à partir de votre dépôt subversion. Toutefois, si vous utilisez un pur dépôt git, il fonctionne à merveille.

25voto

Daniel Fanjul Points 2375

Je voudrais utiliser submodules (comme Pat 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 à l'histoire:

J'ai eu un problème similaire il y a plusieurs mois: ~21Gb de mp3, non classifié (mauvais noms, les mauvaises id3, ne sais pas si j'aime que le mp3 ou pas...), et reproduite dans trois ordinateurs.

J'ai utilisé un disque dur externe avec le git de pensions et j'ai cloné dans chaque ordinateur. Puis, j'ai commencé à les classer dans la voie habituelle (pousser, tirer, fusion... de supprimer et de renommer un grand nombre de fois).

À la fin, je n'avais qu' ~6 go de mp3 et ~83Gb dans le .git dir. J'ai utilisé git-écrire-arbre et git-commit-arbre pour créer un nouveau commit, sans commettre ancêtres, et a commencé une nouvelle branche de pointage à qui s'engagent. Le "git log" pour la branche seulement montré un commit.

Ensuite, j'ai supprimé l'ancienne direction de la, a gardé que la nouvelle branche, supprimé la ref-journaux, et exécutez la commande "git prune": après que, mon .git dossiers pondérée seulement ~6 go...

Vous pourriez "purger" l'énorme entrepôt de temps à autre, de la même façon: Votre "git clone", ce sera plus rapide.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X