Il y a six mois, je présentais l'idée de stocker toutes mes données dans git, incluant mes documents personnels, mes photos, vidéos, fonds d'écran, etc. Je vous propose aujourd'hui un retour d'expérience.
Mais comment je faisais avant...
Bon, pour la faire courte, je ne reviendrais pas en arrière. Les avantages conférés par git pour tout ce qui concerne le développement se retrouvent dans la gestion de documents au quotidien, avec quelques bonus.
Pour commencer, cela simplifie quelque peu la synchronisation entre machines. En ce qui me concerne, je n'ai pas besoin de synchronisation automatique (j'ai juste à faire un git pull de temps en temps), mais il est bon de savoir que des solutions existent pour cela (voir mon précédent article).
Ensuite, cela a un côté extrêmement rassurant. Le fonctionnement même de git fait que l'on dispose presque toujours de deux copies d'un même fichier (une sur la machine "de travail" et une sur le serveur git). Si l'on considère que j'utilise un laptop, un mac et un PC de bureau, j'ai déjà quatre copies de mon fichier sur quatre supports différents (incluant le serveur git, donc). En plus, on a cette sensation extrêmement satisfaisante que nos fichiers sont "à l'abris", comme figés dans le temps. Une sensation peut-être dangereuse, qui ne doit pas dispenser d'avoir une copie de sauvegarde supplémentaire...
Il est vrai qu'avec un bon système de synchronisation de fichiers, cet argument ne tient plus. Mais en pratique, pour avoir testé pas mal de solutions de ce genre, rien n'est aussi pratique, confortable et performant que "mon" système à base de git. Je pense en particulier à NextCloud et son client desktop qui utilise le protocole WebDAV qui est une plaie avec les "micro"-fichiers (genre les dotfiles), les "mega"-fichiers (tout ce qui pourrait dépasser les paramètres d'upload du serveur NextCloud, typiquement les vidéos), et qui n'est pas particulièrement rapide. Je ne vais pas vous faire l'intégralité des solutions que j'ai testé ici, étant donné que globalement, j'ai à faire les mêmes reproches à toutes les plateformes.
Les agréments
Là où les autres solutions se traînent, l'usage de git maximise ma bande passante de 1Gbit/s entre mes machines et mon serveur. En vérité, c'est la première fois dans ma vie de geek que le facteur limitant est mon réseau filaire fixe. En fait, c'est surtout que le débit est maintenu du début à la fin du transfert réseau, peu importe la taille des fichiers.
Bien évidemment, une caractéristique intrinsèque de git - absente des systèmes de stockage "conventionnels" - est le versioning. Fondamentalement absent d'une installation native de n'importe quel système d'exploitation (à moins d'en faire la configuration initialement), parfois compliqué à mettre en place à posteriori, le versioning est simplifié avec git. Normal : c'est fait pour, et en plus, j'ai de l'expérience en tant que développeur... Naviguer dans l'historique de n'importe quel fichier est redoutable de simplicité, je ne vous ferai pas l'affront de vous expliquer git.
Combiné à une interface web, par exemple Gitea, on évitera les écueils de la ligne de commande : on dispose d'une meilleure visibilité globale sur un "projet" entier (comprendre : "documents personnels", "documents administratifs", "photos", etc.), et d'un ensemble de fonctionnalités que git n'offre pas nativement. Celle que j'utilise le plus souvent concerne les tickets qui me permettent de planifier des modifications ou des corrections. Je peux aussi utiliser ma CI/CD (Drone, en l'occurrence) pour convertir tout un projet Markdown en HTML, ou pour mettre à jour le firmware de mes projets à base d'ESP8266 simplement avec un git push.
Cette interface web permet d'aller encore plus loin grâce à la visualisation de fichiers intégrée : pratique pour avoir un dépôt "livres", où l'on n'a plus besoin de rien pour lire en ligne, ou pour visualiser les photos ou les vidéos, avec, cependant, quelques limitations que nous verrons plus loin.
La gestion des permissions se fait relativement simplement et assez finement : il "suffit" de créer un compte utilisateur supplémentaire et lui attribuer des droits. Pour ajouter un droit en écriture, il faut également une clé SSH. Pas forcément évident pour des débutants, mais pour des utilisateurs habitués, cela se fait en quelques instants. En plus de cela, passant par SSH, tout est chiffré.
Autre bonus, octroyé cette fois par git-lfs : la possibilité de stocker des fichiers volumineux, tels que des vidéos ou des ISOs. En ce qui me concerne, j'utilise Drone pour générer des ISOs bootables pour mes systèmes sous NixOS, que je peux donc versionner sans le moindre mal.
Enfin, Gitea (et sans doute d'autres forges logicielles) permet d'utiliser un système de fichiers différent de celui du système d'exploitation. Dans mon cas, j'utilise un couple de serveurs MinIO qui m'offre redondance et haute-disponibilité (bien que dans l'absolu, trois noeuds constitueraient un idéal de sécurité). J'ai trouvé ça incroyablement facile à configurer et incomparablement plus performant, surtout comparé aux solutions à base de GlusterFS ou Ceph, respectivement lente et complexe.
Les désagréments
Comme je le prévoyais, il faut être bien organisé pour utiliser git pour stocker tous ses fichiers. Rien n'est gravé dans le marbre évidemment, mais il est moins aisé de s'organiser avec git qu'avec une arborescence de fichiers classiques.
Exemple typique : les photos. En ce qui me concerne, je les classe sur disque par date de prise de vue, dans une arborescence de type année/mois/jour, éventuellement avec une profondeur supplémentaire pour le contexte si le cas s'y prête. Je ne me suis pas compliqué la vie, j'ai créé un dépôt richard/photos dans lequel j'ai mis toute mon arborescence telle quelle.
Sauf que j'ai quelques gigaoctets de photos. Comme je change d'avis comme de chemise, je supprime souvent mon dossier photos de ma machine "de travail", je bricole, je fais des trucs, et puis je veux à nouveau mon dossier photos. Je dois resynchroniser plusieurs gigaoctets de données. C'est chiant. Pas spécifique à git, ça serait chiant, peu importe le système de stockage.
Du coup, je vais changer de stratégie. Plutôt que de stocker toutes mes photos dans un seul dépôt, j'ai créé une organisation git, et plusieurs dépôts au sein de cette organisation : photos/dinosaures-schleich, photos/mariage, photos/USA-2016, etc. Ceci met en évidence une contrainte de git avec laquelle il faut composer : la hiérarchie initiale d'un système de stockage ne peut se faire que sur une profondeur de deux niveaux (l'organisation puis le dépôt). D'où l'idée de bien réfléchir en amont à la façon de structurer son stockage. Comme dit, rien n'est figé, et on peut relativement facilement changer d'avis en cours de route, mais plus un dépôt est gros, plus difficile ce sera de le scinder, c'est mathématique.
Toujours concernant la gestion des photos : je ne regrette pas l'absence d'une solution complète de gestion avec tagging et tout le bordel. Cependant, j'aurai apprécié de pouvoir visualiser plusieurs photos côte-à-côte, comme dans un explorateur de fichiers, plutôt qu'avoir une liste de fichiers, cliquer sur l'un d'entre eux, se rendre compte que ce n'est pas la photo que je cherchais, revenir en arrière, passer au fichier suivant, etc.
J'aimerais que la visualisation des fichiers soit plus universelle et permette dans certains cas la modification des fichiers concernés : certaines vidéos sont difficiles à lire directement depuis l'interface de Gitea (une intégration de ffmpeg pourrait résoudre le problème), et il manque des outils pour les formats bureautiques. Autrement dit : j'adorerai disposer d'une intégration de Collabora à Gitea, par exemple, qui permettrait dans la foulée de faire un commit des modifications en cours, se substituant à l'enregistrement classique.
Il manque encore deux ou trois fonctionnalités à Gitea pour tenir tête à d'autres forges (typiquement, Gitlab et GitHub) :
- la possibilité d'héberger directement des pages statiques (l'équivalent de GitHub Pages), ce qui permettrait de monter très facilement des blogs ou des photoblogs
- l'équivalent des Gist, qui me permettrait de me passer de Hedgedoc
Conclusion
Je n'ai pas l'intention de repasser à un système de stockage traditionnel. Je suis pleinement satisfait de git pour tout et pas seulement le code. Il y a quelques "défauts" mineurs, pas rédhibitoires, mais rien qui nuise à l'utilisation quotidienne. Au contraire : mes données sont en sûreté, en tout cas c'est mon ressenti, j'ai une excellente visibilité à long terme sur des fichiers qui changent rarement, il y a la sécurité des accès, la versatilité de git + lfs et des supports de stockages et donc la souplesse, etc.
Si l'aventure vous tente, je vous encourage à passer à l'action !