Pour ignorer des fichiers dans Git, il n’y a pas que `.gitignore`

 (nelson.cloud)
11 points par GN⁺ 4 시간 전 | 3 commentaires | Partager sur WhatsApp
  • Les règles d’ignorance de fichiers de Git se répartissent en trois niveaux selon leur portée de partage : .gitignore, .git/info/exclude et ~/.config/git/ignore
  • Comme .gitignore est committé avec le code du dépôt, c’est l’endroit où placer les règles partagées que l’équipe ou le projet doivent appliquer ensemble
  • Pour des éléments comme des fichiers personnels ou des fichiers de travail locaux, utiles dans le dépôt mais difficiles à formaliser comme règle d’équipe, il est plus approprié d’utiliser .git/info/exclude
  • Les fichiers à exclure de façon répétée dans tous les dépôts, comme .DS_Store sur macOS, peuvent être placés dans ~/.config/git/ignore, le fichier d’ignore global à la machine
  • git check-ignore -v <nom_du_fichier> est utile pour identifier quelle règle ignore un fichier, et s’il n’existe aucune règle correspondante, la commande n’affiche rien

Où s’appliquent les règles d’ignore de Git

  • Git peut gérer les règles d’ignorance de fichiers à trois emplacements
    • .gitignore
    • .git/info/exclude
    • ~/.config/git/ignore

.gitignore : les règles partagées commit­tées dans le dépôt

  • .gitignore est le fichier habituel dans lequel on écrit les noms des fichiers à ignorer
  • Il est check-in dans Git avec le reste du code
  • Les fichiers qui correspondent aux règles de .gitignore ne sont pas pris en compte lors de l’exécution des commandes git

.git/info/exclude : les règles personnelles propres à un dépôt

  • Le fichier exclude se trouve dans le répertoire .git de chaque dépôt Git
  • Les modifications de ce fichier ne sont pas check-in dans Git
  • Dans un nouveau dépôt Git, il contient généralement quelques lignes de commentaires
  • Il convient aux fichiers que l’on veut ignorer uniquement pour un dépôt donné, sans les ajouter à .gitignore
    • Exemple : si vous ne voulez pas committer dans le dépôt un notes.txt nécessaire uniquement à votre workflow personnel, ni l’ajouter au .gitignore du projet, vous pouvez ajouter notes.txt à .git/info/exclude

~/.config/git/ignore : les règles globales de la machine

  • Le fichier ignore global se trouve dans ~/.config/git/ignore, dans le répertoire personnel
  • Les noms de fichiers ajoutés ici sont ignorés globalement au niveau de la machine
  • Il n’est pas check-in dans Git et n’est lié à aucun dépôt en particulier
  • C’est l’endroit idéal pour placer les fichiers que vous souhaitez ignorer dans tous les dépôts Git de votre ordinateur
    • Exemple : sur macOS, il est pertinent d’y ajouter .DS_Store

Changer le chemin du fichier d’ignore global

  • Le fichier d’ignore global peut être redirigé vers un autre fichier
  • Pour utiliser .gitignore_global comme fichier d’ignore Git global, exécutez la commande suivante
git config --global core.excludesFile ~/.gitignore_global
  • Pour revenir au paramétrage par défaut, exécutez la commande suivante
git config --global --unset core.excludesFile

Vérifier quelle règle ignore un fichier

  • Avec git check-ignore -v <nom_du_fichier>, vous pouvez vérifier par quelle règle un fichier donné est ignoré
  • Pour voir comment .DS_Store est ignoré, exécutez la commande suivante dans un dépôt Git
git check-ignore -v .DS_Store
  • Si le .gitignore du dépôt ignore .DS_Store, voici un exemple de sortie
$ git check-ignore -v .DS_Store
.gitignore:1:.DS_Store	.DS_Store
  • Si le .git/info/exclude du dépôt ignore .DS_Store, voici un exemple de sortie
$ git check-ignore -v .DS_Store
.git/info/exclude:7:.DS_Store	.DS_Store
  • Si le fichier global ~/.config/git/ignore ignore .DS_Store, voici un exemple de sortie
$ git check-ignore -v .DS_Store
/Users/nelson/.config/git/ignore:2:.DS_Store	.DS_Store
  • Si le fichier d’ignore global personnalisé .gitignore_global ignore .DS_Store, voici un exemple de sortie
$ git check-ignore -v .DS_Store
/Users/nelson/.gitignore_global:1:.DS_Store	.DS_Store
  • S’il n’existe aucune règle qui ignore un fichier donné, la commande git check-ignore -v n’affiche absolument rien

À lire aussi

3 commentaires

 
sudoeng 1 시간 전

Il pourrait aussi être utile de mettre des éléments comme le spec de travail ou le fichier plan.md dans .git/info/exclude.
 
yangeok 2 시간 전

Ah, donc il y avait aussi un réglage à la racine haha
 
GN⁺ 4 시간 전
Commentaires Hacker News

  • Article intéressant, mais il manque ma fonctionnalité Git préférée de quasi-ignorance : .gitattributes
    Ce fichier permet d’indiquer à Git d’« ignorer » les différences de certains fichiers. Par exemple, dans un projet Node, package-lock.json ressemble presque à du bruit du point de vue de Git. On n’y voit que d’énormes diffs avec les versions précises des bibliothèques, alors que les informations de version réellement lisibles par un humain se trouvent séparément dans package.json
    En ajoutant une ligne package-lock.json -diff dans le .gitattributes à la racine du projet, le fichier continue d’être indexé et commit, mais git diff n’affiche plus ces énormes différences sans intérêt

    • package-lock.json ne devrait pas être du bruit. Si on ne cherche pas volontairement à le mettre à jour, il ne devrait pas changer ; sinon on s’expose sans raison à un risque de supply chain
      Si des changements dans package-lock.json apparaissent souvent de façon inattendue, c’est qu’il y a un problème
    • package-lock.json montre toutes les dépendances transitives, alors que package.json ne montre que les dépendances directes. Dire que ce dernier contient les « vraies versions lisibles par un humain » n’est pas exact
      Les deux n’ont pas le même rôle, et dire qu’on peut toujours ignorer les diffs du fichier de verrouillage est dangereux
    • Du point de vue de quelqu’un qui fait des mises à niveau de dépendances et cherche l’origine de bugs, je serais vraiment agacé si git diff ne montrait pas les diffs du fichier de verrouillage
      Je comprends que cela puisse ressembler à du bruit ligne par ligne, mais quand on en a besoin, c’est indispensable

  • Les règles d’exclusion globales / par utilisateur devraient être bien plus connues. Je reçois souvent des changements qui veulent ajouter dans le .gitignore de tous les projets des fichiers liés à l’IDE, à l’OS ou à l’IA ; quand on explique qu’on peut les mettre dans une configuration standard pour qu’ils soient ignorés partout, sans toucher à chaque projet, et sans risquer de les commit par erreur dans les projets dont le .gitignore n’a pas été mis à jour, la plupart des gens apprécient
    Ma règle personnelle est d’utiliser le .gitignore du dépôt uniquement pour les éléments propres au dépôt, comme les artefacts de build ou les dossiers de dépendances, et de laisser la plupart des outils utilisateur dans la configuration de chacun

    • Le fait qu’il faille souvent rappeler l’existence du .gitignore global est justement la conséquence naturelle de ce principe selon lequel le .gitignore du dépôt ne doit servir qu’aux éléments propres au dépôt
      Pour faire perdre moins de temps à tout le monde, il vaut mieux simplement mettre ce genre de fichiers dans le .gitignore de tous les projets
    • J’ai toujours mis ces fichiers dans le .gitignore du projet pour éviter que quelqu’un les ajoute au projet par ignorance
      On finirait de toute façon par les retirer de Git, et cette personne en souffrirait, donc c’était une manière préventive d’être aimable. Je serai peut-être moins aimable à l’avenir
    • Je préfère la solution gitignore, parce qu’elle survit même à la reconstruction d’un conteneur de développement
      S’il faut éviter gitignore, on peut certes restaurer ou conserver la configuration avec un script de génération ou un volume, mais cela impose un script supplémentaire ou une configuration de montage devcontainer au lieu d’une simple ligne dans .gitignore
    • N’y a-t-il pas une contradiction à voir continuellement le même mauvais comportement, tout en imposant une règle stricte qui interdit explicitement la manière la plus simple de le corriger ?

  • Pour la configuration Git globale et les fichiers d’ignore, je pense qu’il vaut mieux utiliser ~/.config/git/ignore et ~/.config/git/config que créer ~/.gitignore_global et modifier la configuration
    Si on utilise ~/.config/ pour plusieurs usages, cela réduit fortement le nombre de dotfiles à la racine
    Si Git exclude est moins utilisé, c’est parce qu’il n’est pas commit dans le dépôt, donc il faut le recréer chaque fois qu’on veut s’en servir. Ce n’est pas pour dire que c’est mauvais, seulement pour expliquer pourquoi c’est moins utilisé

    • Et en bonus, si vous versionnez le répertoire ~/.config, vous pouvez ensuite modifier et partager ces fichiers plus facilement
    • On peut aussi utiliser ~/.cvsignore pour d’autres outils qui lisent le même fichier

  • Je ne sais plus où j’ai appris ça, mais j’ai ajouté attic à mon ignore Git global
    Ça permet de créer dans n’importe quel projet un répertoire attic pour y stocker divers éléments qui ne devraient jamais être commit. Je n’ai encore jamais vu de dépôt qui vérifie réellement l’existence d’un tel répertoire

    • On peut aussi faire quelque chose d’un peu inverse, mais il faut le faire au cas par cas
      S’il y a un répertoire comme attic, on peut créer attic/.gitignore avec /** dedans ; ainsi, ce répertoire et tout ce qu’il contient sont ignorés, y compris le fichier ignore lui-même
      En général, je donne à ma version de ce répertoire un nom d’un seul caractère, U+1F4A9, mais HN n’autorise pas son insertion dans les commentaires
    • Dans mon cas, j’utilise aux
      J’y mets un .gitignore ne contenant qu’une étoile *, ce qui masque le dossier lui-même et tout son contenu
    • Je fais ça aussi. Sauf que je l’appelle .local
    • Chez moi, c’est scratch/
      Jusqu’ici, ça ne m’a encore jamais causé de problème

  • Concernant les ignores par utilisateur, sur macOS, on dit souvent qu’il est idéal d’y ajouter .DS_Store, mais il faut alors que tous les utilisateurs Mac du projet le fassent
    S’il y en a plus d’un ou deux, il peut être préférable de ne pas laisser cela à la charge de chacun

    • Je ne sais pas exactement d’où cela vient, mais sur mes deux Mac (un sous Ventura, un sous Sequoia), il y a un fichier ~/.gitignore_global avec une entrée .DS_Store, et la configuration Git globale contient aussi le paramètre pour ignorer les entrées de ce fichier
      Sur le Mac récent, la date du fichier est antérieure de deux jours à la commande, et je ne me souviens pas l’avoir configuré moi-même, donc j’ai l’impression que cela était fourni par défaut. L’ancien Mac devait probablement être similaire, et vu les versions de macOS, c’est peut-être le comportement par défaut depuis assez longtemps
      Il est donc possible que l’époque où il fallait ajouter .DS_Store/ au .gitignore soit désormais révolue
    • C’est une manière assez particulière de considérer minorité et majorité. Si un seul utilisateur macOS travaille sur dix projets, faut-il ajouter cette ligne aux dix projets, ou vaut-il mieux que ce soit géré du côté de cet unique utilisateur ?

  • Waouh, comment ai-je pu passer à côté de ça ? Je suis développeur logiciel professionnel depuis 20 ans et je n’ai utilisé que .gitignore
    Je réalise que je ne me suis même jamais demandé s’il existait une meilleure manière d’éviter d’encombrer .gitignore avec toutes sortes d’exclusions qui ne concernent que moi. J’acceptais simplement le monde tel qu’il se présentait
    Aujourd’hui, le monde va un peu mieux

  • J’utilise énormément .git/info/exclude. C’est parfait pour des scripts / Makefile utilisés seulement en local et dont les collaborateurs n’ont ni besoin ni même la possibilité de se servir

    • Je serais curieux d’avoir des exemples de scripts que les autres collaborateurs ne peuvent pas utiliser. Par exemple, des scripts pour un flux de travail lié aux PR ?
    • Depuis assez longtemps, j’utilise une fonction shell qui envoie dans .git/info/exclude tous les fichiers non suivis affichés par git status
      En général, je l’applique après avoir fait les add et commit de tout ce que je veux réellement mettre dans le dépôt

  • J’utilise aussi des fichiers excludes de cette manière pour appliquer une configuration Git au niveau du projet différente dans un répertoire de projet contenant plusieurs dépôts
    https://laszlo.nu/blog/project-level-git-config.html

  • Voici quelques alias liés que j’utilise
    assume = update-index --assume-unchanged
    unassume = update-index --no-assume-unchanged
    assumed = "!git ls-files -v | grep ^h | cut -c 3-"
    unassumeall = "!git assumed | xargs git update-index --no-assume-unchanged"
    assumeall = "!git st -s | awk {'print $2'} | xargs git assume"

  • Pour les fichiers déjà suivis, il y a aussi git update-index --[no]-skip-worktree
    Ça peut être utile pour des expérimentations locales, mais comme Git ne met pas vraiment cette fonctionnalité en avant, c’est un peu pénible à utiliser. Il faut se souvenir qu’on l’a activée, et si on l’oublie, cela peut bloquer d’autres opérations comme un checkout