Les images doivent-elles être stockées dans un référentiel git?
Pour une équipe distribuée qui utilise 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. La taille du dossier qui les contient ne fera qu'augmenter à mesure que les images seront ajoutées. Une préoccupation est que le dossier d'images peut atteindre une grande taille au fil du 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 partager des fichiers binaires nécessaires dans des projets auxquels une équipe distribuée peut facilement accéder?
Vos images sont-elles des œuvres originales ou peuvent-elles être récupérées (garanties?) 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 qu'une sauvegarde, et ils sont là où vous en avez besoin.
Peuvent-ils être modifiés pour modifier l'apparence du logiciel, accidentellement ou intentionnellement? Oui - alors ils DOIVENT être contrôlés en quelque sorte, pourquoi utiliser une autre façon quand vous avez déjà une solution parfaite. Pourquoi introduire le contrôle de version "copier et renommer" depuis les âges sombres?
J'ai vu l'illustration originale d'un projet entier devenir "pouf" lorsque le disque dur MacBook du graphiste est mort, tout cela parce que quelqu'un, avec une sagesse infinie, a décidé que "les binaires n'appartiennent pas au contrôle du régime", et les graphistes (au moins celui-ci) ) ne sont généralement pas adaptés aux sauvegardes.
La même chose s'applique à tous les fichiers binaires qui répondent aux critères ci-dessus.
La seule raison de ne pas le faire est l'espace disque. J'ai peur, à 100 $/téraoctet, que cette excuse soit un peu mince.
Pourquoi diable non? :)
Le stockage de fichiers binaires est considéré comme une mauvaise pratique, oui, mais je ne me suis jamais trop inquiété des images.
Pire cas, si vous en avez des tonnes, stockez-les ailleurs ou utilisez des externes ou une extension pour le support binaire. Et si les images ne sont pas modifiées aussi souvent, alors où est le problème? Vous n'obtiendrez pas un gros delta gras. Et s'ils sont supprimés au fil du temps, c'est uniquement votre serveur qui souffre un peu du stockage de l'historique, mais les clients ne verront rien.
À mon avis, vous ne devriez pas vous en soucier - étant donné que vous n'en stockez pas les Go.
Ce que vous pourriez faire, c'est seulement stocker des images "source": SVG, macros LaTeX, etc ... et avoir les images finales générées par votre build système. C'est probablement encore mieux, si vous le pouvez. Sinon, ne vous embêtez pas.
(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 métriques si vous le pouvez)
Pour plus d'informations, vous pouvez consulter ces questions et réponses:
Cette question est assez ancienne mais c'est une question courante qui se pose lorsque l'on traite avec Git et il y a des progrès sur les solutions modernes pour stocker des fichiers volumineux dans un référentiel Git depuis la dernière réponse.
Pour stocker des fichiers volumineux dans Git, il existe les projets suivants:
- git-annex - Cela existe depuis un certain temps, mais franchement, sa complexité fait obstacle.
- git-media - Aucune expérience personnelle avec celui-ci. Semble également assez complexe.
- git-fit - Une tentative de créer un plugin plus simple. Nécessite un stockage S3. Bien que j'apprécie la simplicité, ma principale préoccupation avec le plugin est qu'il est assez inconnu et maintenu par 1 individu (divulgation complète, je suis le seul autre contributeur à ce moment et c'était pour un problème trivial).
- git-lfs - Bien que je n'aie pas beaucoup utilisé cela, il semble que ce soit le Saint Graal. Il est soutenu par Github et est disponible sur tous leurs référentiels en octobre 2015 et met la complexité de la gestion des fichiers sur le site en stockant vos référentiels. Le seul inconvénient est que c'est assez nouveau, donc au-delà de Github il n'y a pas beaucoup de support, bien que Gitlab a également un support , comme Gitea , et Bitbucket a fait allusion à un soutien à l'avenir .
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 binaires dans le contrôle de code source" est présenté pour une raison spécifique: si vous avez du code source qui compile, ne stockez pas la compilation réelle, mais uniquement le code source. Les images et les éléments visuels n'ont pas de "source", ils devraient donc être suivis dans le contrôle de version.
Je crois que la manière recommandée avec Git est d'utiliser un sous-module (introduit dans Git 1.5.3) qui est fondamentalement un référentiel séparé qui est associé au principal. Vous stockez vos images (et autres ressources binaires) dans le sous-module. Cela peut ensuite être extrait avec le référentiel principal ou laissé, selon ce qui est requis.
De http://book.git-scm.com/5_submodules.html
"La prise en charge des sous-modules de Git permet à un référentiel de contenir, en tant que sous-répertoire, une extraction d'un projet externe. Les sous-modules conservent leur propre identité. superproject ") peut facilement cloner tous les sous-modules à la même révision. Des extractions partielles du superprojet sont possibles: vous pouvez dire à 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 pour élaguer/réduire la 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 libérez 2.0. Un client qui utilise 1.0 et ne peut pas passer à 2.0 décide alors qu'il souhaite que le programme soit dans une autre langue. Ils vous donnent 1 G $ pour le faire, alors vous dites sûr. Mais dans une culture différente, certaines de vos photos n'ont pas de sens, il faut donc les changer ...
Si vous souhaitez garder vos images sous contrôle de code source, c'est facile, basé sur 1.0 vous apportez des modifications aux images (entre autres), construisez, libérez. Si vous ne les aviez pas dans le contrôle de code source, vous auriez beaucoup plus de mal, car vous devriez trouver les anciennes images, les changer, puis les construire.
S'il fait partie du projet, il doit être dans le VCS. La meilleure façon d'y parvenir peut dépendre du VCS ou de la façon dont vous organisez un projet. Peut-être un repo pour les concepteurs, et seulement les résultats dans le repo du codeur, ou seulement les `` sources d'image '' (j'ai eu un projet avec un seul fichier .svg, 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'ai eu aucun problème à mettre des quantités "habituelles" de graphiques (maquettes, concepts et graphiques de page) pour les 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 délicat.
git est très bon avec les fichiers texte, mais de par sa nature même n'est pas trop chaud avec les binaires. Vous aurez des problèmes avec la taille des données transférées lorsque vous clonerez ou pousserez, vos répertoires .git grandiront, et vous pourriez vous retrouver dans un bon bordel avec la fusion (c'est-à-dire comment fusionner 2 images!)
Une réponse consiste à utiliser des sous-modules, car cela signifie que le lien entre votre projet et les images sera plus faible - vous n'aurez donc pas à gérer les images comme si elles faisaient partie de votre source, tout en les gardant sous contrôle et sans avoir soucis de les ramifier - en supposant que le sous-projet est juste un référentiel "plat" de données qui ne passe pas par le même roulement au cours du processus de développement habituel.
L'autre réponse est de les mettre dans un projet différent, de ne jamais le ramifier et de s'assurer que tous ceux qui s'engagent dans ce projet le poussent immédiatement en amont - ne laissez jamais 2 personnes changer la même version du fichier - vous trouverez cela le plus difficile aspect car 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 réponse consiste à les placer dans un SCM différent entièrement mieux adapté à l'utilisation d'images.
Pour ajouter à la réponse de @ haylem, notez que la taille joue un grand rôle à cet égard. Selon le VCS, il peut ne pas fonctionner correctement avec des tonnes d'images. Lorsque des clones ou de grosses poussées commencent à prendre toute la nuit, il est vraiment trop tard car toutes les images sont déjà dans votre référentiel.
Prévoyez de grandes images et une croissance future. Vous ne voulez pas entrer deux ans dans ce projet et avoir un "oh merde, peut-être que le repo est un peu trop gros."
Je suis tout à fait d'accord que leur stockage technique et économique est possible. Question: "Ces images font-elles partie du produit d'expédition ou du contenu d'un produit d'expédition?". Non pas que vous ne pouvez pas stocker de contenu dans GIT (ou tout autre VCS), mais qu'il s'agit d'un problème distinct pour un VCS distinct.