Stocker ses fichiers dans des dépôts git

En résumé : j’utilise git-lfs pour stocker tous mes documents personnels, administratifs, photos, musiques, vidéos, et ça convient bien à mon usage.

Contexte

J’aimerais bien me passer de Syncthing, et depuis que j’ai abandonné mon NAS Synology, je ne trouve aucune solution de synchronisation de fichiers équivalente à Synology Drive.

• Nextcloud : franchement, je ne sais pas comment ce truc tourne. Encore une monstruosité PHP que je range aux côtés de Wordpress et Prestashop. Ça me désespère en tant que développeur PHP… La synchronisation des fichiers est lente (Webdav…) et foireuse (il n’aime pas les fichiers préfixés par un point, trop longs, etc.), sans parler de la lourdeur du truc côté serveur (autant niveau base de données qu’espace disque), les mises à jour où il faut faire une offrande aux dieux pour qu’elles passent (et que les plugins suivent). Le client est probablement le pire que j’ai testé.
• Seafile : je suis à peu près certain que c’est ce qui sert de base à Synology Drive, donc théoriquement ça aurait pu me convenir, mais le système de stockage en backend n’est pas portable ; il faut passer à la version “Pro” pour stocker les fichiers dans un backend S3, et le montage de volumes via fuse semble compliqué/lourd. En plus, j’ai trouvé que les performances de synchronisation n’étaient pas folichonnes (mais pas catastrophiques non plus).
• Syncthing : options par défaut qui ne me conviennent pas, re-synchro chiante à cause des ID de machine qui changent dès qu’on fait un pet de travers, essaye un peu trop de communiquer avec l’extérieur à mon goût. Synchro relativement rapide par contre.

À l’exception de mes projets de dev, qui sont de toute façon dans des dépôts git, mes autres documents ne changent pas fréquemment. Donc finalement, je réalise qu’avoir un outil qui tourne en permanence en tâche de fond ne m’est pas vraiment indispensable. La synchro m’intéresse pour les images ou la musique, mais je les modifie tellement rarement qu’une synchro en temps-réel n’est pas pertinente ; je peux me permettre de faire un git pull de temps en temps…

La solution : git-lfs

Ça fait longtemps que je réfléchi à la question, lu quantité d’articles traitant du sujet, tant en provenance de partisans que de détracteurs, quoique ces derniers se font de plus en plus rares. De toute façon, je ne risque pas grand chose à essayer alors voilà : je vais désormais stocker tous mes documents dans des dépôts git.

En ce qui me concerne, je ne vois que des avantages :

• j’utilise déjà git pour mes projets de dev, j’ai donc déjà toute l’infrastructure sous la main
• même si ce n’était pas le cas, je peux utiliser n’importe quel hébergeur de services git (mais bon, je parle de mes documents personnels que je préfère donc garder dans mon réseau local…)
• je peux garder une trace de l’historique de modification de tous mes fichiers, plus seulement de mes projets dev
• l’extension lfs est faite pour stocker des gros fichiers (et nativement supportée par Gitea), et me semble donc adéquate pour la musique, les vidéos, les photos RAW
• je me passe d’un processus qui tourne en arrière-plan, autant côté client que côté serveur (dans la mesure où j’ai de toute façon un serveur git qui tourne) - je peux même me passer d’une autre méthode d’accès à mes fichiers, et donc virer samba/NFS/whatever
• si un jour je ressens à nouveau le besoin d’une synchro en temps-réel, je peux me tourner vers SparkleShare sans rien changer à mes habitudes
• je trouve que la sauvegarde et la restauration de mes fichiers en cas de pépin est beaucoup plus simple que les procédures habituelles, et c’est dû au fonctionnement-même de git : si j’ai un grave problème sur une des machines clientes, il existe toujours au moins une copie de mes fichiers sur le réseau (sur le serveur et/ou sur les autres clients). Et si le serveur git nécessite une restauration, j’ai les dépôts répartis sur les machines clientes, il n’y a qu’à faire des git push.
• Gitea (et les autres forges logicielles) intègre nativement la prévisualisation des PDF ou des images, l’écoute des fichiers audio, la lecture des fichiers vidéos, etc. Pratique pour un accès occasionnel sans cloner tous les documents ! S’il y avait aussi des éditeurs pour les fichiers OpenDocument, je serai comblé !
• en bonus, si j’ai envie de m’amuser, je pourrais utiliser Drone-CI et là c’est tout un monde qui s’ouvre à moi : automatisation d’export de mes photos dans un format adapté au web, conversion automatique de fichiers, génération automatique de documents via pandoc, etc. ; ces exemples me concernent directement et me trottent dans la tête depuis longtemps pour mes cas d’usage, mais j’imagine qu’il y en aurait bien d’autres… rien que le fait d’écrire ça fait naitre tout un tas d’idées : tags automatique sur les musiques, suppression de certains en-têtes EXIF sur certaines photos, etc.

Et comme je teste ça depuis quelques jours, je peux déjà constater que ça fonctionne mieux que ce que j’espérais, en particulier en ce qui concerne la synchronisation de beaucoup de fichiers de taille réduite (typiquement, de vieilles photos en jpeg dans des résolutions inférieures à 1920x1080). Habituellement, c’est ce qui pose le plus de problèmes aux autres solutions de stockage que j’ai testé, y compris via samba. Le débit s’effondre assez vite dans un tel cas de figure. git est d’office optimisé pour gérer de nombreux petits fichiers, et heureusement lfs ne vient pas plomber ces optimisations.

Dans l’exemple d’environ 5000 fichiers de moins de 5Mo, j’ai un débit constant de 85Mo/s au minimum sur une connexion gigabit (dont le maximum théorique est donc de 125Mo/s). De fait, la synchro est très rapide, beaucoup plus que via webdav par exemple… Je peux donc rajouter la rapidité à ma liste d’avantages.

Enfin, dernier avantage et non des moindres, c’est que c’est très simple à mettre en place. Il n’y a qu’à informer lfs des types de fichiers qu’il doit gérer :

git lfs track "*.pdf" # Pour stocker les PDF dans lfs...

Cette commande aura pour effet de créer un fichier .gitattributes (qu’il est aussi possible de modifier manuellement), et c’est ce fichier que git va utiliser pour déterminer les fichiers à stocker dans lfs. Tout le reste se fait via les commandes git classiques.

Inconvénients

Si ça vous gonfle de faire un git commit et git push à chaque fois que vous modifiez un fichier et de faire un git pull sur les autres machines sur lesquelles vous voulez synchroniser vos fichiers, c’est sûr que cette solution ne vous conviendra pas, mais n’oubliez pas que SparkleShare peut faire tout ça pour vous.

Je pense que l’utilisation de git pour stocker ses documents personnels nécessite une bonne organisation pour être optimale. J’ai créé un certain nombre de dépôts, pour les musiques, pour les vidéos, pour les photos, pour les fonds d’écran, pour les documents administratifs, pour les documents professionnels, etc. Si on n’est pas habitué à git, ça peut être intimidant de jongler avec tout ça. On peut très bien fonctionner avec un seul dépôt ceci-dit, peut être que j’ai fait de l’overengineering…

Une “limitation” de lfs qui ne me concerne pas mais dont il faut être conscient :

Why doesn’t Git LFS handle files larger than 4 GiB on Windows?

Git LFS itself handles these files just fine. However, Git LFS is usually invoked by Git, and Git itself on Windows doesn’t handle files using smudge and clean filters (like Git LFS) that are larger than 4 GiB. As soon as Git handles this, Git LFS will work with it automatically.

In the mean time, you can set the environment variable GIT_LFS_SKIP_SMUDGE to 1 and run git lfs pull to pull down the LFS files. This bypasses Git’s smudging functionality and therefore avoids its limitations.

De manière générale, lisez la FAQ et le reste du wiki de lfs.