Ignorer des fichiers avec Git

Par Maxime Bréhin • Publié le 10 avril 2023 • 3 min

Lorsqu’on travaille avec Git, on souhaite rarement versionner tous les fichiers d’un projet. Qu’il s’agisse de fichiers liés au système d’exploitation, de fichiers techniques liés à un éditeur / EDI, de fichiers sensibles (clés de sécurités, configuration, etc) ou simplement de fichiers générés localement (logs, fichiers temporaires, etc.), on veut éviter de les partager.

Git dispose d’un mécanisme pour les ignorer. Un fichier ignoré ne pourra pas être ajouté au projet et n’apparaîtra pas parmi les fichiers listés par Git (voir la commande git status).

# Si j’essaie d’ajouter un fichier ignoré, Git m’envoie bouler 😅
$git add log/development.log

The following paths are ignored by one of your .gitignore files:
log/development.log
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"

Plusieurs manières de procéder

La meilleure manière de faire consiste à créer un fichier .gitignore à la racine du projet.

Ce fichier doit être versionné / ajouté au projet pour que ses règles soient appliquées chez tou·te·s les participant-e·s au projet.

Il existe certes des alternatives, mais on les classe parmi les FBI™ (Fausses Bonnes Idées) :

1. plusieurs fichiers .gitignore dans le projet (un par répertoire, par exemple) ;
2. un fichier global au compte, via la configuration, et donc non versionné ;
3. le fichier .git/info/exclude, non versionné / partagé.

Pour ne pas te laisser sur ta faim, je vais argumenter un peu :

1. Plusieurs fichiers .gitignore

Pourquoi créer plusieurs fichiers là où tu peux en avoir un seul, plus facile à maintenir ?

2. Un fichier global

L’idée peut paraître intéressante pour définir des règles globales à notre compte et applicables sur l’ensemble des projets sur notre poste (en plus des règles locales à chaque projet), sauf que…

• ces règles ne seront pas partagées ;
• nos collègues risquent d’intégrer des fichiers que nous aurions ignorés de notre côté.

Si vraiment tu souhaites tenter ça, tu peux regarder la commande :

git config --global core.excludesfile <chemin-du-fichier-global-d-exclusion>

Tu ne pourras pas dire que je ne t’ai pas prévenu·e 😉.

3. Le fichier .git/info/exclude

Mêmes arguments que précédemment : pas de partage, donc quel intérêt ?

Syntaxe

Côté syntaxe, on utilise une syntaxe existante et robuste : les globs. On peut renseigner des noms / chemins de fichiers ou répertoires précis, ainsi que des motifs. On peut même spécifier des négations (ce qu’on ne veut pas ignorer), ce qui est utile lorsqu’on souhaite renseigner des exceptions à un motif plus global.

# N’importe quel fichier portant le nom `.env`, y compris dans les sous-répertoires
.env
# Tous les fichiers ayant l’extension `.tmp`
*.tmp
# Si je veux restreindre au répertoire courant
/config.sample
# Le répertoire `tmp` et tout ce qu’il peut contenir
/tmp
# On autorise une exception dans le répertoire de logs, le fichier `.keep`.
# Pour ça on doit autoriser le répertoire
!/log
# En revanche on n’autorise pas les fichiers qu’il contient,
# ni les sous-répertoires
/log/*
# …à l’exception du fichier `.keep`
!/log/.keep

Mes fichiers étaient déjà versionnés

Tu risques d’être confronté·e un jour à un cas de figure un peu particulier où tu souhaites ignorer des fichiers qui sont déjà versionnés. L’ajout de la règle au .gitignore n’est pas suffisante, tes modifications apparaissent toujours, disponibles à l’ajout 😨. Tu dois en plus “sortir” le fichier de la gestion de versions. Forcément, Git propose une commande pour ça :

git rm --cached fichier-à-retirer

La suppression du fichier est enregistrée dans Git, mais pas sur le disque (c’est tout l’intérêt de l’option --cached). Tu gardes donc ton fichier, mais désormais il est considéré comme exclu (si tu as renseigné la règle dans le .gitignore, hein !).

Attention cependant, tout l’historique du fichier reste présent dans Git. Tu ne fais que cesser de le versionner à partir de maintenant. Si tu veux le retirer ainsi que toutes ses traces, je te recommande…

• de te poser la question : est-ce vraiment utile ?
• si oui, d’utiliser alors un outil pour retravailler tout l’historique projet : filter-repo.

Je veux ajouter un fichier ignoré

Tu as deux solutions :

1. Soit tu changes les motifs ignorés, donc le fichier .gitignore, en utilisant éventuellement une négation (ce qu’on a vu en exemple avec la syntaxe) ;
2. Soit tu forces l’ajout avec un git add --force.

Comme je l’ai expliqué avant, si un fichier est versionné, le .gitignore n’agit plus dessus. Donc en forçant l’ajout une première fois, tu es tranquille pour la suite.

Gabarits pour le .gitignore

Tu te doutes bien qu’on utilise généralement les mêmes socles, éditeurs, systèmes d’exploitation. Il est donc naturel qu’on retrouve les mêmes motifs à ignorer d’un projet à l’autre.

Il existe des solutions pour récupérer facilement ces gabarits. On t’explique tout ça dans ce protip complémentaire.