J'apprends git les semaines précédentes environ et j'aime vraiment la façon dont il fonctionne par rapport à SVN. La principale raison pour laquelle je cherche à passer pleinement à cela est le fait que la fusion est censée être beaucoup plus facile avec peu de conflits et le fait que je puisse commettre localement. Cela favorise l'utilisation de nombreuses branches (comme une branche par billet / émission / tâche / etc.) et promouvoir de nombreux engagements. Je n'utilise que des succursales si je dois dans SVN (puisque les fantasmes produisent souvent des conflits) et je ne vous engageons que lorsque je suis sûr que je suis sûr que le problème est corrigé (au lieu de commits supplémentaires, qui serait plus agréable).
Maintenant, une préoccupation que j'ai sur GIT, comme je l'ai lu, c'est sur les fichiers non textuels / grands projets. Par exemple, je travaille sur un projet de jeu actuellement contrôlé dans SVN. Maintenant, avec un projet de jeu, il y aura beaucoup de fichiers non texte tels que l'art, le son et d'autres fichiers binaires et certains des fichiers peuvent être assez gros. Comment bien git git gérer les fichiers non-texte / gros fichiers binaires? Quelles sont certaines des considérations que je dois garder à l'esprit si je veux porter un tel projet pour git?
4 Réponses :
Git gère parfaitement les fichiers binaires. Il vous suffit de garder à l'esprit que toutes les versions du fichier binaire sont conservées localement. Si un fichier binaire (disons une image) change fréquemment, vous finirez par remplir votre espace local avec toute la version de l'image.
C'est mon expérience que GIT fait un bon travail de compression des fichiers binaires. N'oubliez pas que git pack ou git gc une fois de temps en temps
SVN gère-t-il des fichiers binaires différemment ou les mêmes que ceux mentionnés ici (stocker une copie complète du fichier pour chaque version)?
Depuis avec git, vous avez à l'histoire complète dans votre repo local, cela consommera plus d'espace qu'un projet SVN. Avec SVN Si vous voulez revenir en arrière, vous avez besoin du repo à distance pour le télécharger à partir de (le serveur a tout l'historique). Avec Git, vous avez déjà toute la version localement.
@Ryanzec - Voir ma réponse pour la façon dont SVN gère les fichiers binaires et leurs diffs
L'une des grandes différences de la manière dont les données GIT stockent les données par rapport aux autres systèmes de contrôle de la version sont que GIT stocke complètement le contenu du fichier en tant qu'objet unique. Cela signifie que chaque version de chaque fichier existe sous forme de fichier complet dans votre référentiel (c'est très comprimé). Ainsi, tandis que d'autres VCS stockent les différences / deltas entre deux versions et, comme cela gère des fichiers binaires et textuels différemment (comme des fichiers binaires ne sont pas si difficiles), GIT ne gère que toutes identiques.
En tant que tel, travailler avec des fichiers binaires dans GIT n'est pas différent de l'utilisation d'un autre type de fichier. Il vous suffit de garder à l'esprit que les fichiers en version très volumineux augmenteront beaucoup la taille de votre référentiel (comme chaque version de ce grand fichier est stockée tel qu'il est, même si le changement binaire réel était petit). La compression de Git travaille toutefois des merveilles et vous fait remarquer cela habituellement. Surtout si vous ne parlez que d'actifs d'un programme, vous n'aurez probablement aucune difficulté.
Chaque objet est un fichier individuel uniquement initialement. Après assez de commits, ou lorsque le repo est gc d, ou lorsque vous le clonez, ils seront délivrés et emballés, ce qui rendra la taille du référentiel concurrentiel avec un référentiel de subversion.
@JleeDev: Qu'est-ce que je voulais dire avec "existe comme un fichier complet", c'est que le fichier (contenu) est entièrement stocké, non pas s'il existe nécessairement un seul fichier qui stocke le blob. Comme je l'ai dit, le git de compression effectue est très efficace afin que vous ne remarquez généralement pas que chaque version de fichier est stockée indépendamment dans le référentiel.
Cela dépend simplement de votre niveau d'abstraction. Mais il est vrai que vous ne le remarquez généralement pas.
La compression des données déjà compressées ne donne généralement pas de bons résultats. Il n'y a rien de magique sur Git qui compressera davantage un JPG. Faire un delta est le seul moyen de réduire la taille - et une fois delta-fié, sa conservée comme delta (évidemment) ne le fait pas différent de tout autre SCM.
Ajout de la réponse de @ Poke
Je suis un utilisateur de git passionné ces jours-ci, mais ayant travaillé dans un vaste projet où il y avait beaucoup de fichiers binaires - principalement des zips - à manipuler - j'ai trouvé SVN d'être plus efficace que Git. La taille du repo git a été gonflée en un rien de temps pendant que la taille d'un référentiel SVN similaire ne varie pas beaucoup. Clonant un tel repo Git, en particulier sur des endroits distribués géographiquement, était un cauchemar. GIT n'a également pas de fonctionnalité de clone partielle, quelque chose que nous faisons dans SVN tout le temps - à la caisse, juste un dossier particulier. Il y a une caisse partielle dans Git, mais vous devez toujours cloner tout le repo.
Notez que si un fichier est ou non binaire n'affecte pas la quantité de Espace de référentiel utilisé pour stocker des modifications à ce fichier, cela n'a pas d'incidence sur la quantité de trafic entre client et serveur. Pour le stockage et la transmission Des fins, Subversion utilise un diffing méthode qui fonctionne également bien sur fichiers binaires et texte; c'est Complètement sans rapport avec le diffing méthode utilisée par la commande 'svn diff' '.
Premièrement, les zips sont eux-mêmes déjà compressés, de sorte que le git de compression GZIP s'applique bien sûr ne fonctionnera pas beaucoup. Deuxièmement, vous n'avez pas nécessairement de cloner un référentiel. En fait, le clonage est quelque chose que vous ne faites que au début pour obtenir votre référentiel local mis en place. Vous pouvez toutefois simplement ajouter d'autres référentiels sous forme de télécommandes, puis effectuez des extratures partielles de branches, etc.
Indépendamment de cela, sauf si vous avez constamment changé de fichiers binaires (par exemple lorsque votre éditeur utilise un format binaire, par exemple les fichiers Flash IDE's .fla), à l'aide de GIT pour stocker des actifs binaires (sons, images) est Pas un problème du tout, et surtout les petits inconvénients n'échirez pas les avantages que vous obtenez d'utiliser GIT en premier lieu.
Je ne pense pas que vous comprenez ma préoccupation concernant le clonage. Lorsque je dois installer un nouveau repo local, je dois cloner, quel que soit un clone étant un travail unique. Et récupérer une branche particulière n'est toujours pas partiellement partielle du monde SVN des choses. Et dans tous les grands projets de projet, les fichiers binaires vont être changés très fréquemment. Y compris les actifs. Altase un sous-ensemble d'entre eux, qui suffit pour commencer à donner les problèmes.
Tout d'abord, les zips sont eux-mêmes déjà comprimés, de sorte que le git de compression GZIP s'applique bien sûr ne fonctionnera pas beaucoup. - Exactement, ce n'était pas le cas avec SVN et c'était mon point.
D'autres réponses ont abordé les choix ici, mais il existe également la possibilité d'utiliser SVN pour les fichiers binaires (s'ils changeront beaucoup) et gitent pour tout le reste. Pendant la phase de construction, vous pouvez utiliser des scripts pour récupérer la ressource binaire de SVN.
Avez-vous envisagé d'utiliser des fichiers d'artefactory ou similaires aux magasins (Versed)? jfrog.com/artifactory