Gérer et stocker des fichiers volumineux dans Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Git permet de conserver l’empreinte de votre code source petit, car les différences entre les versions sont facilement sélectionnées et le code est facilement compressé. Les fichiers volumineux qui ne sont pas compressés correctement et qui changent entièrement entre les versions (comme les fichiers binaires) présentent des problèmes lorsqu’ils sont stockés dans vos dépôts Git. Les performances rapides de Git proviennent de sa capacité à traiter et à basculer vers toutes les versions d’un fichier à partir de son stockage local.

Si vous avez des fichiers volumineux et indifféreux dans votre dépôt (tels que des fichiers binaires), vous conservez une copie complète de ces fichiers dans votre dépôt chaque fois que vous validez une modification. Si de nombreuses versions de ces fichiers existent dans votre dépôt, elles augmentent considérablement le temps d’extraire, de brancher, d’extraire et de cloner votre code.

Quels types de fichiers devez-vous stocker dans Git ?

Valider le code source et non les dépendances

À mesure que votre équipe travaille avec des éditeurs et des outils pour créer et mettre à jour des fichiers, vous devez placer ces fichiers dans Git afin que votre équipe puisse profiter des avantages du flux de travail Git. Ne commettez pas d'autres types de fichiers dans votre dépôt : par exemple, les fichiers DLL, de bibliothèque, et autres dépendances que votre équipe ne crée pas mais dont votre code dépend. Fournissez ces fichiers via la gestion des packages à vos systèmes.

La gestion des packages regroupe vos dépendances et installe les fichiers sur votre système lorsque vous déployez le package. Les packages sont versionnés pour s’assurer que le code testé dans un environnement s’exécute de la même façon dans un autre environnement, tant que les environnements ont les mêmes packages installés.

Ne pas valider les sorties

Ne validez pas les fichiers binaires, les logs, la sortie de suivi ou les données de diagnostic provenant de vos compilations et tests. Il s’agit de sorties de votre code, et non du code source lui-même. Partagez les journaux et les informations de traçage avec votre équipe via les outils de suivi des éléments de travail ou par le biais du partage de fichiers en équipe.

Stocker des sources binaires petites et rarement mises à jour dans Git

Les fichiers sources binaires rarement mis à jour ont relativement peu de versions validées. Ils ne prennent pas beaucoup d’espace si leur taille de fichier est petite. Les images pour le web, les icônes et d’autres ressources d’art plus petites peuvent tomber dans cette catégorie. Il est préférable de stocker ces fichiers dans Git avec le reste de votre source afin que votre équipe puisse utiliser un flux de travail cohérent.

Ne validez pas les ressources binaires volumineuses et fréquemment mises à jour

Git gère une version principale d’un fichier, puis stocke uniquement les différences de cette version, dans un processus appelé deltification. La compression des fichiers et de la deltification permettent à Git de stocker l’intégralité de votre historique de code dans votre dépôt local. Les fichiers binaires volumineux changent généralement entièrement entre les versions et sont souvent déjà compressés. Ces fichiers sont difficiles à gérer pour Git, car les différences entre les versions sont volumineuses.

Git doit stocker l’intégralité du contenu de chaque version du fichier et a des difficultés à économiser de l’espace par le biais de laltification et de la compression. Le stockage des versions complètes de ces fichiers entraîne l’augmentation de la taille du dépôt au fil du temps. La taille accrue du dépôt réduit les performances de branchement, augmente les temps de clonage et étend les exigences de stockage.

Stratégies d’utilisation de fichiers sources binaires volumineux

• Ne validez pas les archives compressées de données. Il est préférable de décompresser les fichiers et de valider les sources différentes. Laissez Git gérer la compression des données dans votre dépôt.
• Évitez de valider le code compilé et d’autres dépendances binaires. Validez la source et générez les dépendances, ou utilisez une solution de gestion de package pour la version et fournissez ces fichiers à votre système.
• Stockez la configuration et d’autres données structurées dans des formats de texte brut différents, tels que JSON.

Qu’est-ce que Git LFS ?

Lorsque vous avez des fichiers sources avec de grandes différences entre les versions et les mises à jour fréquentes, vous pouvez utiliser le stockage de fichiers volumineux Git (LFS) pour gérer ces types de fichiers. Git LFS est une extension de Git qui fournit des informations décrivant les fichiers volumineux d’un commit dans votre dépôt. Il stocke le contenu du fichier binaire dans un stockage distant distinct.

Lorsque vous clonez et basculez des branches dans votre dépôt, Git LFS télécharge la version correcte à partir de ce stockage distant. Vos outils de développement locaux fonctionnent de manière transparente avec les fichiers comme s'ils avaient directement été validés dans votre répertoire.

Avantages

L’avantage de Git LFS est que votre équipe peut utiliser le flux de travail Git de bout en bout familier, quel que soit le fichier créé par votre équipe. LFS gère les fichiers volumineux pour les empêcher d’affecter négativement le référentiel global. En outre, à partir de la version 2.0, Git LFS prend en charge le verrouillage de fichiers pour aider votre équipe à travailler sur des ressources volumineuses et indifférables telles que des vidéos, des sons et des cartes de jeu.

Git LFS est entièrement pris en charge et gratuit dans Azure DevOps Services. Pour utiliser LFS avec Visual Studio, vous avez besoin de Visual Studio 2015 Update 2 ou version ultérieure. Suivez simplement les instructions pour installer le client, configurez le suivi LFS pour les fichiers sur votre dépôt local, puis envoyez vos modifications à Azure Repos.

Limites

Git LFS présente certains inconvénients que vous devez prendre en compte avant de l’adopter :

• Chaque client Git que votre équipe utilise doit installer le client Git LFS et comprendre sa configuration de suivi.
• Si le client Git LFS n’est pas installé et configuré correctement, vous ne verrez pas les fichiers binaires validés via Git LFS lorsque vous clonez votre dépôt. Git télécharge les données qui décrivent le fichier volumineux (c’est-à-dire ce que Git LFS valide dans le dépôt) et non le fichier binaire. La validation de fichiers binaires volumineux sans le client Git LFS installé envoie (push) le binaire à votre dépôt.
• Git ne peut pas fusionner les modifications de deux versions différentes d’un fichier binaire, même si les deux versions ont un parent commun. Si deux personnes travaillent sur le même fichier en même temps, elles doivent collaborer pour rapprocher leurs modifications afin d’éviter de remplacer le travail de l’autre. Git LFS fournit un verrouillage de fichiers pour vous aider. Les utilisateurs doivent toujours s’occuper d’extraire toujours la dernière copie d’une ressource binaire avant de commencer le travail.
• Actuellement, Azure Repos ne prend pas en charge l’utilisation de Secure Shell (SSH) dans les dépôts avec des fichiers suivis Git LFS.
• Si un utilisateur fait glisser un fichier binaire via l’interface web dans un dépôt configuré pour Git LFS, le fichier binaire est validé sur le dépôt, et non sur les pointeurs qui seraient validés via le client Git LFS.
• Bien qu’il n’existe pas de restriction stricte de taille de fichier, l’espace libre disponible du serveur et la charge de travail actuelle peuvent limiter les performances et les fonctionnalités.
• La limite de temps d’un chargement de fichier est d’une heure.

Format de fichier

Le fichier écrit dans votre dépôt pour un fichier suivi Git LFS comporte quelques lignes avec une paire clé/valeur sur chaque ligne :

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

Problèmes connus

Si vous utilisez une version de LFS antérieure à la version 2.4.0 avec Azure DevOps Server, une étape de configuration supplémentaire est nécessaire pour s’authentifier via NTLM au lieu de Kerberos. Cette étape n’est plus nécessaire à partir de LFS 2.4.0, et nous vous recommandons vivement de mettre à niveau.