Les images doivent-elles être stockées dans un référentiel git?

Pour une équipe distribuée utilisant Git et Github comme contrôle de version, les images doivent-elles également être stockées dans le référentiel git?

Pour la plupart, les images ne seront pas modifiées. Le dossier qui les contient ne fera que croître au fur et à mesure de l'ajout des images. Un problème est que le dossier d'images peut atteindre une taille importante avec le temps en combinant de grandes images, ou juste beaucoup d'entre elles.

Est-ce considéré comme une meilleure pratique? Quelles autres alternatives existe-t-il pour le partage des fichiers binaires nécessaires aux projets auxquels une équipe distribuée peut facilement accéder?

Vos images sont-elles une oeuvre originale ou peuvent-elles être récupérées d’ailleurs? Sont-ils nécessaires pour expédier une unité logicielle construite à partir de la source? S'ils sont originaux, ils doivent être sauvegardés. Mettez-les dans votre contrôle de révision, s'ils ne changent jamais, la pénalité d'espace est la même que pour une sauvegarde, et c'est là que vous en avez besoin.

Peuvent-ils être édités pour changer l'apparence du logiciel, accidentellement ou intentionnellement? Oui, alors ils DOIVENT être contrôlés d’une manière ou d’une autre, pourquoi utiliser une autre méthode alors que vous avez déjà une solution parfaite. Pourquoi introduire le contrôle de version "copier et renommer" depuis les âges sombres?

J'ai vu des illustrations d'un projet entier devenir "pouf" lorsque le disque dur MacBook du concepteur graphique est mort, tout cela parce que quelqu'un, avec une sagesse infinie, a décidé que "les fichiers binaires n'appartiennent pas au contrôle de la version", et les concepteurs graphiques (du moins celui-ci ) n’ont pas tendance à bien fonctionner avec les sauvegardes.

Il en va de même pour tous les fichiers binaires répondant aux critères ci-dessus.

La seule raison pour ne pas le faire est l'espace disque. J'ai peur à 100 $ / téraoctet, cette excuse est un peu mince.

Pourquoi diable pas? :)

Stocker des fichiers binaires est considéré comme une mauvaise pratique, oui, mais je ne me suis jamais trop soucié des images.

Dans le pire des cas, si vous avez des tonnes, stockez-les ailleurs ou utilisez des externes ou une extension pour le support binaire. Et si les images ne sont pas souvent changées, où est le problème? Vous n'obtiendrez pas un gros delta. Et s’ils sont supprimés au fil du temps, seul votre serveur souffre d’un peu de stockage de l’historique, mais les clients ne verront rien.

À mon avis, vous ne devriez pas vous en inquiéter, à condition de ne pas en stocker de Go.

Ce que vous pouvez faire cependant, n’est que de stocker des images "sources": SVG, macros LaTeX, etc ... et de faire en sorte que les images finales soient générées par votre système de construction. C'est probablement encore mieux, si vous le pouvez. Si non, alors ne vous inquiétez pas.

(Tout cela étant dit, Git brille pour les fichiers texte, mais n’est pas le meilleur VCS pour les images. Donnez-nous plus de contexte et de mesures si vous le pouvez)

Pour plus d'informations, vous pouvez consulter ces questions et réponses:

• Stockage de fichiers image dans SubVersion / Git
• Git vs SVN avec des fichiers non-textuels
• Gestion de gros fichiers binaires avec Git et Git-submodule

Cette question est assez ancienne, mais c’est une question courante qui se pose lorsqu’on traite avec Git et des progrès ont été réalisés dans les solutions modernes de stockage de gros fichiers dans un dépôt Git depuis la dernière réponse.

Pour stocker de gros fichiers dans Git, il existe les projets suivants:

• git-annex - Cela existe depuis un moment, mais franchement, la complexité l’entrave.
• git-media - Aucune expérience personnelle avec celui-ci. Cela semble assez complexe aussi.
• git-fit - Une tentative pour créer un plugin plus simple. Nécessite un stockage S3. Bien que j'apprécie la simplicité, mon souci principal avec le plugin est qu'il est relativement inconnu et maintenu par une personne (divulgation complète, je suis le seul autre auteur à l'heure actuelle et c'était pour une question triviale).
• git-lfs - Bien que je ne l'utilise pas beaucoup, il semble que ce soit le Saint Graal. Il est soutenu par Github et est disponible sur tous leurs pensions à partir d'octobre 2015 et met la complexité de la gestion des fichiers sur le site pour stocker vos pensions. Le seul inconvénient, c’est que c’est relativement nouveau, donc au-delà de Github, il n’ya pas beaucoup de support, bien que Gitlab le soit aussi , tout comme Gitea , et Bitbucket a fait allusion au support dans le futur .

TLDR: si vous le pouvez, utilisez git-lfs pour stocker des images ou d’autres fichiers binaires dans git.

L'ensemble "ne stocke pas les fichiers binaires dans le contrôle de code source" est défini pour une raison spécifique: si le code source est compilé, ne stockez pas la compilation proprement dite, mais uniquement le code source. Les images et les éléments visuels n'ont pas de "source", ils doivent donc être suivis dans le contrôle de version.

Je pense que la méthode recommandée avec Git consiste à utiliser un sous-module (introduit dans Git 1.5.3), qui est essentiellement un référentiel distinct associé au principal. Vous stockez vos images (et autres actifs binaires) dans le sous-module. Cela peut ensuite être extrait avec le référentiel principal ou laissé, en fonction des besoins.

De http://book.git-scm.com/5_submodules.html

"Le support des sous-modules de Git permet à un référentiel de contenir, en tant que sous-répertoire, le contrôle d'un projet externe. Les sous-modules conservent leur propre identité. superproject ") peut facilement cloner tous les sous-modules lors d'une même révision. Des extractions partielles du superprojet sont possibles: vous pouvez demander à Git de ne cloner aucun, certains ou tous les sous-modules."

De plus, la taille ne devrait pas être un problème important si les images ne changent pas souvent. Vous pouvez également exécuter des commandes d'élagage / réduction de taille, telles que:

git gc
git gc-aggressive
git prune

Oui .

Disons que vous publiez la version 1.0 du logiciel. Pour la version 2.0, vous décidez de refaire toutes les images avec des ombres. Donc, vous faites cela, et la version 2.0. Ensuite, un client qui utilise la version 1.0 et ne peut pas passer à la version 2.0 décide qu'il souhaite le programme dans une autre langue. Ils vous donnent 1G $ pour le faire, alors vous dites bien. Mais dans une culture différente, certaines de vos images n'ont pas de sens, vous devez donc les changer ...

Si vous souhaitez conserver vos images dans le contrôle de la source, cela est simple: sur la base de la version 1.0, vous apportez des modifications aux images (entre autres), générez, libérez. Si vous n'aviez pas ces éléments dans le contrôle de source, vous auriez beaucoup plus de difficulté, car il vous faudrait trouver les anciennes images, les modifier, puis les compiler.

Si cela fait partie du projet, il faut que ce soit dans le VCS . La meilleure façon d’atteindre cet objectif dépend du VCS ou de la manière dont vous organisez un projet. Peut-être un référentiel pour les concepteurs, et uniquement les résultats dans le référentiel du codeur, ou uniquement les «sources d’image» (jadis, j’avais un projet avec un fichier .svg uniquement, et les images étaient générées via make / inscape cli).

Mais, si un VCS ne peut pas gérer cela, ou devient inutilisable, je dirais que ce n’est pas le bon outil pour votre travail.

Jusqu'à présent, je n'avais aucun problème à mettre des quantités de graphismes «habituelles» (maquettes, concepts et graphiques de page) pour des projets Web dans git.

Si vous stockez vos images dans SCM: oui. Sans aucun doute.

Si vous stockez vos images dans git: cela devient plus compliqué.

git est très bon avec les fichiers texte, mais de par sa nature, il n’est pas trop chaud avec les binaires. Vous aurez des problèmes avec la taille des données transférées lorsque vous clonez ou appuyez sur Puss, vos répertoires .git s'agrandissent et vous risquez de vous perdre dans la fusion (c.-à-d. Comment fusionner deux images!)

Une solution consiste à utiliser des sous-modules, car cela signifie que le lien entre votre projet et les images sera plus faible. Ainsi, vous ne devrez pas gérer les images comme si elles faisaient partie de votre source, tout en les maintenant sous contrôle, sans avoir se soucier de les ramifier - en supposant que le sous-projet est simplement un référentiel «à plat» de données qui ne subit pas le même désordre au cours du processus de développement habituel.

L’autre solution est de les placer dans un projet différent, de ne jamais créer de branche et de s’assurer que tous ceux qui s’engagent dans ce projet le mettent immédiatement en amont - ne laissez jamais deux personnes modifier la même version du fichier - vous trouverez que cela est le plus difficile. l’aspect comme git n’est pas conçu pour un tel flux de travail non distribué. Vous devrez utiliser des méthodes de communication à l'ancienne pour appliquer cette règle.

Une troisième solution consiste à les placer dans un autre SMC totalement mieux adapté au travail avec des images.

Ajoutant à la réponse de @ haylem, notez que la taille joue un rôle important dans cette situation. En fonction du VCS, il peut ne pas fonctionner correctement avec des tonnes d’images. Lorsque des clones ou de grandes pressions commencent à prendre toute la nuit, il est vraiment trop tard car toutes les images se trouvent déjà dans votre référentiel.

Planifiez de grandes images et la croissance future. Vous ne voulez pas avoir deux ans dans ce projet et avoir un "oh merde, peut-être que le repo est un peu trop gros."

Je suis absolument d'accord pour dire qu'il est possible de les stocker techniquement et économiquement. Question que je poserais tel quel "ces images font-elles partie du produit expédié ou du contenu d'un produit expédié?" Non pas que vous ne puissiez pas stocker de contenu dans GIT (ou tout autre VCS), mais qu'il s'agisse d'un problème distinct pour un VCS distinct.