Si les collaborateurs sur votre référentiel n’ont Git LFS pas installé, ils n’ont pas accès au fichier volumineux d’origine. S’ils tentent de cloner votre dépôt, ils récupéreront (fetch) uniquement les fichiers pointeurs et n’auront accès à aucune des données réelles.
Conseil
Pour aider les utilisateurs sans Git LFS activation, nous vous recommandons de définir des instructions pour les contributeurs de référentiel qui décrivent comment utiliser des fichiers volumineux. Par exemple, vous pouvez demander aux contributeurs de ne pas modifier les fichiers volumineux ou de charger les modifications dans un service de partage de fichiers comme Dropbox ou Google Drive. Pour plus d’informations, consultez « Définition de recommandations pour les contributeurs de dépôt ».
Affichage de fichiers volumineux dans les pull requests
GitHub n’affiche pas certains objets Git LFS dans les pull requests. Seul le fichier de pointeur s’affiche, avec un contenu similaire à cela :
+version https://git-lfs.github.com/spec/vi
+id sha256:7194bdd797bde471a6e29b4fa9c8c2278b3c4dadfc5cb2c36d7f4531dc6cb8f
+size 17330
Pour plus d’informations sur les fichiers de pointeur, consultez À propos du stockage de fichiers Git volumineux.
Pour voir les modifications apportées aux fichiers volumineux, clonez la pull request localement pour passer en revue les différences. Pour plus d’informations, consultez « Consulter des pull requests localement ».
Poussée de fichiers volumineux vers des duplications (fork)
La poussée de fichiers volumineux vers les duplications d’un dépôt est prise en compte dans les quotas de bande passante et de stockage du dépôt parent, mais pas dans les quotas du propriétaire de la duplication.
Vous pouvez pousser des objets Git LFS vers des forks publics si le réseau du dépôt contient déjà des objets Git LFS ou si vous disposez d’un accès en écriture à la racine du réseau du dépôt.