Imaginez que vous décidiez d'ajouter un petit formulaire de contact à mon-premier-site, plus tard dans son évolution. Pour l'envoyer par e-mail, vous aurez besoin d'une clé secrète fournie par un service tiers. Vous la stockeriez naturellement dans un fichier à part, par exemple .env, pour ne pas l'écrire en clair dans index.html. Le problème : si vous ne faites rien, Git verra ce fichier exactement comme les autres, prêt à être ajouté et committé. Une fois poussé sur GitHub, un secret publié reste consultable dans l'historique, même si vous le supprimez ensuite. C'est exactement ce que .gitignore permet d'éviter, en amont.

Simulez la situation

Pour comprendre concrètement, créez deux éléments dans mon-premier-site, uniquement pour cet exercice. D'abord un fichier .env à la racine, avec un contenu qui ressemble à un vrai secret, sans en être un :

Puis créez un dossier node_modules contenant un fichier vide quelconque à l'intérieur : ce dossier apparaît dès qu'on installe un outil JavaScript avec npm, et il peut contenir plusieurs milliers de fichiers générés automatiquement, que personne n'a besoin de suivre dans Git. Vous n'avez pas encore ce genre d'outil dans ce projet, mais simuler sa présence permet de voir comment .gitignore réagit avant d'en avoir réellement besoin.

Lancez maintenant git status pour observer le problème.

Les deux apparaissent, prêts à être ajoutés au prochain git add . distrait. C'est exactement ce qu'un fichier .gitignore va empêcher.

Créer le fichier .gitignore

À la racine de mon-premier-site, créez un nouveau fichier nommé exactement .gitignore, avec le point au début et sans extension. Ouvrez-le et ajoutez les deux lignes suivantes.

Chaque ligne est un motif. .env exclut ce fichier précis. node_modules/, avec la barre oblique finale, exclut tout un dossier et son contenu, quel que soit le nombre de fichiers qu'il contient. Enregistrez, puis relancez git status.

.env et node_modules/ ont disparu de la liste. Git continue de savoir qu'ils existent sur le disque, mais il ne les propose plus jamais pour un commit tant qu'ils correspondent à un motif du .gitignore. Seul le fichier .gitignore lui-même apparaît comme non suivi : c'est normal, et c'est même souhaitable de le committer, pour que la règle s'applique aussi si vous clonez ce projet ailleurs plus tard.

Ajoutez-le et committez-le comme n'importe quel autre fichier utile au projet.

Ce que .gitignore ne fait pas

C'est le point le plus important de ce guide, et celui que beaucoup de débutants découvrent trop tard. .gitignore n'agit que sur des fichiers non suivis. Si un fichier a déjà été ajouté et committé par le passé, l'ajouter ensuite à .gitignore ne le retire pas de l'historique existant : Git continue de le suivre normalement, comme si le fichier ignorer n'existait pas pour lui.

Pour arrêter de suivre un fichier déjà committé par erreur, il faut une commande explicite, git rm --cached, suivie du nom du fichier. Elle retire le fichier du suivi Git à partir de maintenant, sans le supprimer de votre disque, mais elle ne supprime pas les anciennes versions déjà enregistrées dans l'historique des commits précédents.

Attention aux secrets déjà publiés

Si un vrai mot de passe, une vraie clé API ou un vrai token a déjà été poussé sur GitHub avant d'être ajouté à .gitignore, ajouter la règle ne corrige pas l'exposition passée : ce secret reste lisible dans l'historique des commits précédents, même après suppression du fichier. La seule action réellement efficace est de révoquer ou changer ce secret immédiatement auprès du service qui l'a fourni. Ne stockez jamais de mot de passe, de token, de clé API ou de clé privée dans un dépôt, même privé.

Comment vérifier qu'un motif fonctionne

Si vous avez un doute sur le fait qu'un fichier soit correctement ignoré, la commande git check-ignore -v, suivie de son nom, indique précisément quelle ligne de quel fichier .gitignore est responsable de l'exclusion. C'est utile quand un motif ne semble pas fonctionner comme prévu, par exemple à cause d'une faute de frappe dans le nom.

Vérifiez que vous avez compris

Vous avez committé .env par erreur il y a deux semaines, avec une vraie clé API dedans. Vous venez d'ajouter .env à votre .gitignore et de le committer. Cette clé API est-elle encore consultable par quelqu'un qui aurait accès à l'historique complet du dépôt ?

Oui, entièrement. Le .gitignore empêche uniquement les futurs ajouts. Les commits passés qui contiennent la clé restent intacts et consultables. La seule solution sûre dans ce cas est de révoquer immédiatement cette clé auprès du service qui l'a émise, puis d'en générer une nouvelle qui, elle, ne sera jamais committée.

Chapitre terminé