git-annex - Outil de gestion de fichiers volumineux pour les utilisateurs de Git

 (git-annex.branchable.com)
21 points par GN⁺ 2025-09-05 | 1 commentaires | Partager sur WhatsApp
  • git-annex est un outil qui permet de gérer de gros fichiers sans stocker directement leur contenu dans un dépôt Git
  • Il permet d’effectuer synchronisation, sauvegarde et archivage en ligne comme hors ligne, tout en garantissant la sécurité grâce aux sommes de contrôle et au chiffrement
  • En appliquant la nature distribuée de Git aux fichiers volumineux, il simplifie le suivi des emplacements et les transferts entre plusieurs disques, serveurs et clouds
  • Il convient aux utilisateurs centrés sur la CLI, tandis que git-annex assistant offre une expérience de type synchronisation de dossiers pour les utilisateurs généralistes
  • C’est un outil qui étend les workflows d’archivage et de déplacement grâce à un format de dépôt simple pour la conservation à long terme et à divers special remotes

Aperçu

  • git-annex est un outil de gestion de fichiers volumineux qui conserve le contenu des fichiers hors de Git et ne gère dans Git que les métadonnées et les informations d’emplacement
    • Le résultat est un historique de commits léger, tout en permettant de stocker et de déplacer facilement de gros binaires
    • Les sommes de contrôle et la prise en charge du chiffrement garantissent l’intégrité et la confidentialité
  • Il permet d’effectuer synchronisation, sauvegarde et archivage aussi bien hors ligne qu’en ligne, et offre des fonctions de gestion du nombre de copies d’un même fichier entre dépôts distribués ainsi que de journalisation
  • Bien qu’optimisé pour les utilisateurs en ligne de commande, il peut aussi être utilisé facilement par le grand public via git-annex assistant, sous la forme d’une synchronisation de dossiers
  • Une documentation de walkthrough est fournie pour permettre aux nouveaux utilisateurs d’apprendre rapidement l’installation et les flux de base

Cas d’usage : Archivist (utilisateur orienté archivage)

  • Même en exploitant plusieurs disques d’archivage hors ligne, il est possible de parcourir et réorganiser tous les fichiers comme s’ils n’en formaient qu’un dans une arborescence de répertoires unique
    • Même si le contenu des fichiers se trouve sur des disques hors ligne, les index et pointeurs permettent de les réorganiser et de les valider sans risque réel de suppression
  • Lorsqu’un fichier donné devient nécessaire, l’outil indique sur quel disque il se trouve et permet de le rendre facilement disponible
    • Chaque disque partage des informations d’emplacement mutuelles, ce qui permet de comprendre l’état global de l’archivage
  • Grâce à un format de dépôt simple, l’accessibilité aux fichiers est préservée à long terme même sans utiliser git-annex ni git
  • Des tâches cron permettent d’archiver automatiquement de nouveaux fichiers la nuit et d’enregistrer les copies intentionnelles ou non, afin de fournir une base pour décider à quel moment une réplication est nécessaire

Cas d’usage : Nomad (utilisateur orienté mobilité)

  • Il permet de gérer de façon cohérente des stockages hétérogènes — ordinateur portable, disques USB / clés USB portables, serveurs distants, stockage cloud chiffré — comme des remotes Git
    • En déplacement, il prend en charge un workflow de transfert différé consistant à accumuler une file d’attente de téléchargements sur le serveur, puis à effectuer les transferts réels dans un lieu où la qualité de connexion est meilleure
  • Il est possible de construire des workflows adaptés au hors ligne, par exemple copier instantanément depuis l’USB puis consommer localement, afin notamment d’économiser la batterie
  • Une fois l’utilisation terminée, on peut désigner ce qui doit être conservé ou supprimé pour récupérer de l’espace local, puis synchroniser les modifications avec le serveur lors de la synchronisation suivante
  • Grâce aux special remotes et aux pipelines de transfert, l’outil permet des déplacements de données souples selon les backends de stockage et les conditions réseau

Fonctions clés et avantages

  • Assure une conservation sûre à long terme grâce à l’adressage par contenu et aux sommes de contrôle, ainsi qu’à la prise en charge du stockage chiffré
  • Grâce au suivi des emplacements (location tracking), il devient possible de connaître clairement l’emplacement de stockage, le nombre de copies et la disponibilité de chaque fichier
  • En appliquant le modèle de gestion de versions distribuée aux fichiers volumineux, il réduit la dépendance à un stockage centralisé et apporte une résilience hors ligne
  • Le mode assistant offre une expérience de synchronisation de dossiers, permettant même aux personnes peu à l’aise avec la CLI de bénéficier d’une ergonomie de niveau glisser-déposer

Résumé des points forts

  • git-annex ne gère dans git que les références des fichiers, ce qui le rend adapté à la manipulation de gros fichiers sans contrainte
  • Sa structure distribuée permet de déplacer, stocker, synchroniser, sauvegarder et versionner librement les fichiers entre plusieurs appareils et emplacements
  • Il offre une intégration et une extensibilité particulièrement fortes pour les scénarios hors ligne et de conservation à long terme, ou pour la gestion fluide de données entre plusieurs appareils et clouds
  • Il convient aussi aux utilisateurs hybrides entre archivage et mobilité, et se révèle utile tant pour les organisations que pour les particuliers grâce à la gestion des politiques de copies et à la diversification des backends
  • En étendant la distribution et la portabilité de Git aux données volumineuses, c’est un outil qui réduit les risques opérationnels et les efforts liés à la conservation et au déplacement sur le long terme

À lire aussi

1 commentaires

 
GN⁺ 2025-09-05
Commentaires Hacker News

  • J’utilise git-annex pour gérer les données sur tous mes disques. Il suit automatiquement sur quel disque se trouve chaque fichier, maintient un nombre suffisant de copies et vérifie les sommes de contrôle de tous les fichiers. Il fonctionne aussi très bien avec des disques hors ligne. git-annex peut sembler un peu difficile à comprendre au début, donc je recommande de créer un dépôt temporaire, de suivre le walkthrough et de pratiquer directement. Les différents workflows valent aussi le détour

    • Je me demande quelle quantité de données tu conserves. De mon côté, je gère avec git-annex sur ZFS environ 100 000 à 1 million de fichiers, pour plusieurs To de photos. Au début, aucun problème, mais récemment tout ralentit progressivement au point qu’une seule commande prend entre 5 et 30 minutes. Je ne sais pas si ça vient de ZFS, de git-annex ou du disque

    • J’envisage depuis longtemps d’utiliser git-annex pour gérer mes données, mais j’ai rencontré quelques problèmes, notamment des frictions pour supprimer complètement des fichiers. Si tu as le temps, je serais curieux que tu partages ta manière de l’utiliser

  • Ce n’est pas indiqué sur la page, mais git-annex a été créé par Joey Hess. Il a aussi développé moreutils et etckeeper

    • Personnellement, le fait le plus marquant est qu’il a été contributeur majeur de Debian pendant des décennies, depuis 1996. Une grande partie de ce qu’on appelle aujourd’hui Linux est passée entre ses mains

  • Il y a eu récemment une discussion sur la nouvelle fonctionnalité native de Git pour la gestion des gros objets ici

    • Pour préciser, j’ai aussi expliqué dans ce commentaire pourquoi, à mon avis, la discussion n’est pas si liée que ça. En pratique, annex traite un sujet un peu différent de celui des « gros fichiers dans git ». On comprend plus facilement git-annex si on le voit comme une manière distribuée, dans l’esprit natif de git, de résoudre le problème du stockage « côté serveur » qu’on rencontre avec LFS et consorts

  • Ce qui me déçoit avec git-annex, c’est Haskell. Ce n’est pas que je déteste le langage, mais j’ai été sidéré par le nombre de dépendances à installer. Une bonne partie ne sert nulle part ailleurs, et les conflits de versions entre applications sont fréquents. C’est particulièrement pénible quand on passe par le gestionnaire de paquets système. Rien qu’en installant annex et pandoc, je me retrouve avec des dizaines de mises à jour de paquets Haskell par jour. Si on utilise une distribution qui compile depuis les sources, c’est un cauchemar. En réalité, je pense que la plupart pourraient être liées statiquement sans problème. Pourtant, dans l’écosystème Haskell, on présente ça comme une conséquence de la modularisation très fine des bibliothèques. Mais il y a aussi d’autres priorités, comme l’administration système, et je n’ai jamais rencontré ce problème avec Rust, Go, Zig, C ou C++. Je ne suis pas hostile à Haskell ni à son écosystème, et j’ai même l’intention de l’apprendre. Mais je me demande pourquoi ce problème existe et quelle en est la solution

    • Le tooling Haskell prend déjà en charge le lien statique. Je maintiens la stack Haskell pour Solus, et pandoc ne dépend que de libc, tous les paquets Haskell étant liés statiquement dans le binaire, exactement comme en Rust. Donc c’est tout à fait faisable. Sur Solus, il y a simplement trop de dépendances, donc on passe directement en statique. J’y vois surtout un choix des mainteneurs de distribution

    • À propos du « la plupart pourraient être liées statiquement sans problème », je me demande si, dans un dépôt de distribution, ce n’est pas au fond une question de politique du gestionnaire de paquets

    • Même en tant que développeur Haskell à plein temps, j’ai la même réticence vis-à-vis des paquets Haskell non liés statiquement. Il existe déjà sur l’AUR des versions liées statiquement, donc ce n’est clairement pas impossible. Je n’ai jamais vraiment creusé pourquoi les packageurs s’obstinent à utiliser le lien dynamique. En général, le lien dynamique peut avoir du sens pour la distribution interne de logiciels, mais ils semblent sans doute projeter ce modèle inutilement sur les distributions

    • Je serais curieux de savoir quel gestionnaire de paquets tu utilises. Sur les systèmes à base d’apt, Haskell ne m’a jamais posé de problème

    • À chaque pacman -Syu, la moitié des mises à jour concerne des paquets Haskell, et ça m’agace. J’imagine que c’est à cause de pandoc ou shellcheck

  • git-annex est une techno vraiment cool. Mais j’ai l’impression qu’il fonctionne surtout bien pour des dépôts mono-utilisateur. Par exemple, quand une personne gère ses données personnelles — fichiers, documents, musique — entre plusieurs appareils. Je l’ai essayé comme mécanisme de synchronisation pour un dépôt collaboratif avec de gros fichiers, mais le système de branche « magic » ne passe pas bien à l’échelle

    • Ça dépend peut-être des usages, mais chez nous, dans notre institution, ça fonctionne au contraire très bien. Nous sommes une institution d’archives numériques et nous utilisons git-annex comme backend de notre stockage interne depuis plus de 10 ans. Nous avons 15 à 20 employés, mais nous gérons sans difficulté plus de 30 To de données et 750 000 fichiers (binaires + métadonnées), répartis sur des centaines de dépôts

  • J’utilise un Forgejo auto-hébergé. Pour l’instant, je n’ai pas encore trouvé ce que git-annex ferait mieux que LFS, et l’installation n’a pas l’air simple. Le fait que git-annex soit écrit en Haskell ne me plaît pas non plus, et j’ai aussi vu qu’il serait environ 50 % plus lent (même si je n’ai trouvé qu’une seule source, donc je ne sais pas si c’est fiable). Les commandes sont sans doute complexes pour une raison, mais on n’a pas la commodité de LFS où il suffit de toucher à .gitattributes pour quasiment tout comprendre. Je n’ai pas non plus l’impression que git-annex offre une transparence comparable à .gitattributes. Et s’il n’existe même pas de tutoriel montrant l’équivalent de git lfs ls-files, je risque de ne pas m’y intéresser. J’ai l’habitude de vérifier avec git status et git lfs ls-files

    • Si c’est lent, ce n’est pas à cause de Haskell. git-annex est un outil de sauvegarde distribué, donc sa lenteur vient surtout de son obsession pour les E/S et la conservation des données. Par exemple, si tu utilises la commande drop, il doit vérifier en temps réel sur tous les remote que le contenu est bien présent, ce qui le ralentit. Avec l’option --fast, entre autres, il peut se contenter des métadonnées locales et sauter cette vérification, ce qui est beaucoup plus rapide (mais un peu plus risqué)

    • LFS et git-annex servent à des usages subtilement différents. LFS convient bien à des dépôts git de développement contenant aussi de gros fichiers, par exemple dans le jeu vidéo. git-annex est plus adapté lorsqu’on veut sauvegarder des données importantes, ou conserver à plusieurs endroits un ensemble de gros fichiers comme un dossier de musique. C’est dans ce second cadre que je l’utilise

    • Il existe un soft fork de Forgejo avec prise en charge de git-annex : forgejo-aneksajo

    • Le plus gros dépôt que je gère avec git-annex fait plusieurs To, répartis sur plusieurs systèmes, avec de nombreux fichiers de plus de 10 Go. Si ce que tu cherches, c’est un équivalent de git-lfs-ls-files, alors git annex list --in here joue probablement un rôle similaire

  • J’aime beaucoup le fait que la documentation en ligne de commande commence d’emblée par des cas d’usage concrets. Beaucoup d’outils démarrent au contraire par des explications d’options obscures qu’on n’utilisera presque jamais, et c’est dommage

  • GitHub n’a pas adopté git-annex et a appliqué à LFS une approche NIH (Not Invented Here) à la sauce Microsoft

    • Moi aussi, je trouve git-annex plus élégant, mais sa compatibilité multiplateforme est plus faible. Pour info, LFS est né d’une collaboration entre GitHub et Bitbucket (ou plutôt un autre forge, je ne me souviens plus exactement lequel). L’un apportait l’implémentation, l’autre le nom, et le tout a fusionné après une rencontre à une conférence Git. Ce qui me déçoit le plus aujourd’hui, ce sont les limites imposées par GitHub sur les gros projets. En plus, avec la politique « il faut rapatrier tous les objets en local avant de pouvoir pousser », une communauté de développement un peu conséquente atteint très vite les limites. À noter : j’ai contribué à git-lfs

    • (Franchement) l’approche NIH de GitHub est perdante sur tous les plans. Il existe une présentation d’un intervenant passionné par git-annex : Staying in Control of your Scientific Data with Git Annex by Yann Büchau

  • Ironiquement, j’ai passé une journée le week-end dernier à coder mon propre système de versioning pour gros fichiers. C’est dire à quel point je n’aime pas git-annex. Il transforme les fichiers en blobs et fait enfler le système de fichiers. Mon objectif principal est la synchronisation distribuée entre fichiers, pas le versioning en soi (je ne comprends d’ailleurs pas pourquoi on aurait besoin de versionner de gros fichiers). Avec l’IA et Python, on peut facilement hacher les fichiers pour créer une table de correspondance, puis ajouter des méthodes utilitaires pour synchroniser les sources avec rclone. Il existe des approches bien plus simples et plus efficaces

  • Je l’ai utilisé pendant plusieurs années, et son principal atout était pour moi l’intégration avec les fournisseurs de stockage cloud et les sauvegardes. Mais cette intégration a toujours été instable et dépendait de plugins tiers peu maintenus. Il y a même eu à une époque un bug de désynchronisation des données, donc j’ai fini par abandonner. Je me demande si ça s’est amélioré au cours des cinq dernières années

    • Je pense que cela dépend du type de fournisseur de stockage cloud. Ceux qui prennent en charge des protocoles standard officiels comme S3, WebDAV ou SFTP sont avantagés. Plus récemment, un special remote basé sur rclone a été intégré directement à git-annex ; il semble mieux maintenu que les anciens remotes tiers et permet de se connecter à presque tous les remotes cloud pris en charge par rclone