7 conseils Git pour gérer votre répertoire personnel

Voici comment j'ai configuré Git pour gérer mon répertoire personnel.

J'ai plusieurs ordinateurs. J'ai un ordinateur portable au travail, un poste de travail à la maison, un Raspberry Pi (ou quatre), un Pocket CHIP, un Chromebook exécutant diverses formes de Linux, etc. J'avais l'habitude de configurer mon environnement utilisateur sur chaque ordinateur en suivant plus ou moins les mêmes étapes, et je me disais souvent que j'appréciais que chacun soit un peu unique. Par exemple, j'utilise plus souvent les alias Bash au travail qu'à la maison, et les scripts d'assistance que j'utilise à la maison peuvent ne pas être utiles au travail.

Au fil des années, mes attentes en matière d'appareils ont commencé à fusionner et j'oubliais qu'une fonctionnalité que j'avais développée sur mon ordinateur personnel n'était pas transférée sur mon ordinateur de travail, et ainsi de suite. J'avais besoin d'un moyen de standardiser ma boîte à outils personnalisée. La réponse, à ma grande surprise, fut Git.

Git est un logiciel de suivi de versions. Il est connu pour être utilisé par les plus grands et les plus petits projets open source et même par les plus grandes sociétés de logiciels propriétaires. Mais il a été conçu pour le code source, et non pour un répertoire personnel rempli de fichiers musicaux et vidéo, de jeux, de photos, etc. J'avais entendu parler de personnes gérant leur répertoire personnel avec Git, mais je pensais qu'il s'agissait d'une expérience marginale réalisée par des codeurs, et non par des utilisateurs réels comme moi.

La gestion de mon répertoire personnel avec Git a été un processus évolutif. J'ai appris et adapté en cours de route. Voici les éléments que vous voudrez peut-être garder à l’esprit si vous décidez de gérer votre répertoire personnel avec Git.

1. Emplacements texte et binaires

^{(Seth Kenlon, CC BY-SA 4.0)}

Lorsqu'il est géré par Git, votre répertoire personnel devient une sorte de no man's land pour tout sauf les fichiers de configuration. Cela signifie que lorsque vous ouvrez votre répertoire personnel, vous ne devriez voir qu'une liste de répertoires prévisibles. Il ne devrait pas y avoir de photos ou de documents LibreOffice égarés, ni de fichiers « Je vais mettre ça ici pendant juste une minute ».

La raison en est simple : lorsque vous gérez votre répertoire personnel avec Git, tout ce qui se trouve dans votre répertoire personnel qui n'est pas validé devient du bruit. Chaque fois que vous effectuez un git status, vous devrez faire défiler tout fichier que Git ne suit pas. Il est donc essentiel de conserver ces fichiers dans des sous-répertoires (que vous ajoutez à votre .gitignore).

De nombreuses distributions Linux fournissent un ensemble de répertoires par défaut :

• Documents
• Téléchargements
• Musique
• Photos
• Modèles
• Vidéos

Vous pouvez en créer davantage si vous en avez besoin. Par exemple, je fais la différence entre la musique que je crée (Musique) et la musique que j'achète pour écouter (Albums). De même, mon répertoire Cinéma contient des films réalisés par d'autres personnes, tandis que Vidéos contient les fichiers vidéo dont j'ai besoin pour le montage. En d’autres termes, ma structure de répertoires par défaut a plus de granularité que l’ensemble par défaut fourni par la plupart des distributions Linux, mais je pense que cela présente un avantage. Sans une structure de répertoires qui vous convient, vous serez plus susceptible de simplement stocker des éléments dans votre répertoire personnel, faute d'un meilleur endroit pour cela, alors réfléchissez à l'avance et planifiez les répertoires qui fonctionnent pour vous. Vous pourrez toujours en ajouter plus tard, mais il est préférable de commencer fort.

2. Configurer votre meilleur .gitignore

Une fois que vous avez nettoyé votre répertoire personnel, vous pouvez l'instancier en tant que référentiel Git comme d'habitude :

$ cd
$ git init .

Votre référentiel Git ne contient encore rien, donc tout ce qui se trouve dans votre répertoire personnel n'est pas suivi. Votre premier travail consiste à passer au crible la liste des fichiers non suivis et à déterminer ce que vous souhaitez ne pas suivre. Pour voir les fichiers non suivis :

$ git status
  .AndroidStudio3.2/
  .FBReader/
  .ICEauthority
  .Xauthority
  .Xdefaults
  .android/
  .arduino15/
  .ash_history
[...]

Selon la durée d'utilisation de votre répertoire personnel, cette liste peut être longue. Les plus faciles sont les répertoires que vous avez choisis lors de la première étape. En les ajoutant à un fichier caché appelé .gitignore, vous dites à Git d'arrêter de les répertorier comme fichiers non suivis et de ne jamais les suivre :

$ \ls -lg | grep ^d | awk '{print $8}' >> ~/.gitignore

Cela fait, parcourez les fichiers non suivis restants affichés par git status et déterminez si d'autres fichiers justifient l'exclusion. Ce processus m'a permis de découvrir plusieurs anciens fichiers et répertoires de configuration obsolètes, que j'ai fini par supprimer complètement, mais aussi certains qui étaient très spécifiques à un ordinateur. J'ai été assez strict ici car de nombreux fichiers de configuration fonctionnent mieux lorsqu'ils sont générés automatiquement. Par exemple, je ne valide jamais mes fichiers de configuration KDE car beaucoup contiennent des informations telles que des documents récents et d'autres éléments qui n'existent pas sur une autre machine.

Je surveille mes fichiers de configuration personnalisés, mes scripts et utilitaires, mes configurations de profil et Bash, ainsi que mes aide-mémoire et autres extraits de texte auxquels je me réfère fréquemment. Si le logiciel est principalement responsable de la maintenance d’un fichier, je l’ignore. Et en cas de doute sur un dossier, je l'ignore. Vous pouvez toujours l'annuler plus tard (en le supprimant de votre fichier .gitignore).

3. Apprenez à connaître vos données

Je suis sur KDE, j'utilise donc le scanner open source Filelight pour avoir un aperçu de mes données. Filelight vous propose un graphique qui vous permet de voir la taille de chaque répertoire. Vous pouvez parcourir chaque répertoire pour voir ce qui occupe tout l'espace, puis revenir en arrière pour enquêter ailleurs. C'est une vue fascinante de votre système et vous permet de voir vos fichiers sous un tout nouveau jour.

^{(Seth Kenlon, CC BY-SA 4.0)}

Utilisez Filelight ou un utilitaire similaire pour rechercher des caches inattendus de données que vous n'avez pas besoin de valider. Par exemple, l'indexeur de fichiers KDE (Baloo) génère un grand nombre de données spécifiques à son hôte que je ne voudrais certainement pas transporter vers un autre ordinateur.

4. N'ignorez pas votre fichier .gitignore

Sur certains projets, je dis à Git d'ignorer mon fichier .gitignore car ce que je veux ignorer est parfois spécifique à mon répertoire de travail, et je ne présume pas que les autres développeurs du même projet ont besoin de moi pour le dire. leur à quoi devrait ressembler leur fichier .gitignore. Étant donné que mon répertoire personnel est destiné à mon usage uniquement, je n'ignore pas le fichier .gitignore de mon domicile. Je le valide avec d'autres fichiers importants, il est donc hérité sur tous mes systèmes. Et bien sûr, tous mes systèmes sont identiques du point de vue du répertoire personnel : ils ont le même ensemble de dossiers par défaut et bon nombre des mêmes fichiers de configuration cachés.

5. Ne craignez pas le binaire

J'ai soumis mon système à des semaines et des semaines de tests rigoureux, convaincu qu'il n'était jamais sage de valider des fichiers binaires dans Git. J'ai essayé les fichiers de mots de passe cryptés GPG, les documents LibreOffice, les fichiers JPEG, PNG, etc. J'avais même un script qui désarchivait les fichiers LibreOffice avant de les ajouter à Git, extrayait le XML à l'intérieur afin que je puisse valider uniquement le XML, puis reconstruisait le fichier LibreOffice afin de pouvoir travailler dessus dans LibreOffice. Ma théorie était que la validation de XML rendrait un référentiel Git plus petit qu'un fichier ZIP (ce qui est en réalité tout ce qu'est un document LibreOffice).

À ma grande surprise, j’ai constaté que la validation de quelques fichiers binaires de temps en temps n’augmentait pas considérablement la taille de mon référentiel Git. Je travaille avec Git depuis assez longtemps pour savoir que si je devais engager des gigaoctets de données binaires, mon référentiel en souffrirait, mais un fichier binaire occasionnel n'est pas une urgence à éviter à tout prix.

Fort de cette nouvelle confiance, j'ajoute des fichiers de polices OTF et TTF à mon dépôt personnel standard, à mon fichier .face pour GDM et à d'autres blobs binaires mineurs accidentels. N'y réfléchissez pas trop, ne perdez pas de temps à essayer de l'éviter ; commettez-le simplement.

6. Utilisez un dépôt privé

Ne validez pas votre répertoire personnel dans un référentiel Git public, même si l'hôte propose des comptes privés. Si vous êtes comme moi, vous disposez de clés SSH, de trousseaux GPG et de fichiers cryptés GPG qui ne devraient pas se retrouver sur le serveur de quelqu'un d'autre que le mien.

J'exécute un serveur Git local sur un Raspberry Pi (c'est plus facile que vous ne le pensez), ce qui me permet de mettre à jour n'importe quel ordinateur à tout moment lorsque je suis à la maison. Je travaille à distance, donc c'est généralement suffisant, mais je peux également accéder à l'ordinateur lorsque je voyage via mon VPN.

7. N'oubliez pas de pousser

Le problème avec Git, c'est qu'il ne transmet les modifications à votre serveur que lorsque vous le lui demandez. Si vous êtes un utilisateur de longue date de Git, ce processus vous est probablement naturel. Pour les nouveaux utilisateurs qui pourraient être habitués à la synchronisation automatique dans Nextcloud ou Syncthing, cela peut prendre un certain temps pour s'y habituer.

Git à la maison

La gestion de mes fichiers courants avec Git n'a pas seulement rendu la vie plus pratique sur tous les appareils. Savoir que je dispose d'un historique complet de toutes mes configurations et scripts utilitaires m'encourage à essayer de nouvelles idées car il est toujours facile d'annuler mes modifications si elles s'avèrent être de mauvaises idées. Git m'a sauvé d'un paramètre umask peu judicieux dans .bashrc, d'un ajout de fin de soirée mal exécuté à mon script de gestion de paquets et d'une idée qui semblait être une bonne idée. -le changement temporel de ma palette de couleurs rxvt - et probablement quelques autres erreurs dans mon passé. Essayez Git chez vous, car une maison qui s'engage ensemble fusionne.