Gérer et stocker des fichiers volumineux dans Git

Article
03/25/2024

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

Git contribue à réduire l’empreinte de votre code source, car les différences entre les versions sont faciles à repérer et le code est facilement compressé. Les fichiers volumineux qui ne peuvent pas être compressés correctement et changent entièrement d'une version à l'autre (comme les fichiers binaires) créent des problèmes quand ils sont stockés dans vos référentiels 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érenciables (tels que des fichiers binaires) dans votre référentiel, gardez-en une copie complète chaque fois que vous en validez une modification. Si plusieurs versions de ces fichiers existent dans votre référentiel, elles augmentent considérablement le temps d’extraction, de branche, de récupération et de clonage de votre code.

Quels types de fichiers devez-vous stocker dans Git ?

Validez le code source, pas 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 validez pas d’autres types de fichiers dans votre référentiel, tels que des DLL, des fichiers de bibliothèque et d’autres dépendances non créés par votre équipe, mais dont le code dépend de votre référentiel. 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, à condition que les packages installés soient les mêmes.

Ne pas valider les sorties

Ne validez pas les fichiers binaires, les journaux, la sortie de suivi ou les données de diagnostic à partir de vos builds 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 trace avec votre équipe via les outils de suivi des éléments de travail ou par le biais du partage de fichiers d’équipe.

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

Les fichiers sources binaires qui sont rarement mis à jour ont relativement peu de versions validées. Ils n'occupent pas beaucoup d’espace si la taille de leur fichier est faible. Les images pour le web, les icônes et d’autres ressources d’art plus petites peuvent entrer 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.

Important

Même les petits fichiers binaires peuvent créer des problèmes s’ils sont souvent mis à jour. Par exemple, 100 modifications apportées à un fichier binaire de 100 Ko utilisent autant d'espace de stockage que 10 modifications apportées à un fichier binaire de 1 Mo. En raison de la fréquence de ses mises à jour, le fichier binaire le plus petit ralentira les performances de branchement plus souvent que le plus volumineux.

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 selon un processus portant le nom de deltification. La compression des fichiers et la deltification permettent à Git de stocker l’intégralité de votre historique de code dans votre référentiel local. En général, les fichiers binaires volumineux changent entièrement d'une version à l'autre et sont souvent déjà compressés. Ces fichiers sont difficiles à gérer pour Git, car les différences entre les versions sont très importantes.

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 la deltification et de la compression. Le stockage des versions complètes de ces fichiers entraîne l’augmentation de la taille du référentiel au fil du temps, ce qui réduit les performances de branchement, allonge les temps de clonage et augmente les besoins de stockage.

Stratégies d’utilisation de fichiers sources binaires volumineux

Ne validez pas les archives compressées des données. Il est préférable de décompresser les fichiers et de valider les sources différenciables. Laissez Git se charger de compresser les données dans votre référentiel.
É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 des mises à jour fréquentes, vous pouvez utiliser le Stockage de fichiers volumineux (LFS) Git pour les gérer. Git LFS est une extension de Git qui fournit des données décrivant les fichiers volumineux associés à une validation dans votre référentiel. Il stocke le contenu du fichier binaire dans un stockage distant séparé.

Lorsque vous clonez et basculez des branches dans votre référentiel, Git LFS télécharge la version correcte à partir de ce stockage distant. Vos outils de développement locaux fonctionnent en toute transparence avec les fichiers comme s’ils étaient validés directement dans votre référentiel.

Avantages

Un avantage de Git LFS est que, quel que soit le fichier qu'elle crée, votre équipe peut utiliser le flux de travail Git de bout en bout qui lui est familier. LFS gère les fichiers volumineux pour les empêcher d’avoir un effet négatif sur le référentiel global. De plus, à partir de la version 2.0, Git LFS prend en charge le verrouillage des fichiers pour aider votre équipe à travailler sur des ressources volumineuses et non modifiables comme les vidéos, les sons et les 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 d'une version plus récente. Suivez simplement les instructions pour installer le client, configurez le suivi LFS pour les fichiers sur votre référentiel 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 utilisé par votre équipe 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 référentiel. Git télécharge les données qui décrivent le fichier volumineux (c’est-à-dire ce que Git LFS valide dans le référentiel) et non pas le fichier binaire. La validation de fichiers binaires volumineux sans le client Git LFS installé envoie le fichier binaire à votre référentiel.
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.
Azure Repos ne prend actuellement pas en charge l’utilisation de Secure Shell (SSH) dans les référentiels contenant des fichiers Git LFS suivis.
Si un utilisateur fait glisser un fichier binaire via l’interface web dans un référentiel configuré pour Git LFS, ce fichier est validé dans le référentiel, et non pas les pointeurs, qui seraient validés via le client Git LFS.
Bien qu’il n’existe pas de restriction stricte en ce qui concerne la taille des fichiers, l’espace libre disponible sur le serveur et la charge de travail actuelle peuvent limiter les performances et les fonctionnalités.
La limite du temps de chargement pour un fichier est d’une heure.

Format de fichier

Le fichier qui est écrit dans votre référentiel pour un fichier Git LFS dont est effectué le suivi possède plusieurs lignes, avec une paire clé/valeur sur chacune d'elles :

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

Remarque

L’URL GitHub incluse pour la valeur de version définit uniquement le type de fichier pointeur LFS. Il ne s'agit pas d'un lien vers votre fichier binaire.

Problèmes connus

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

Partage via