Le .gitignore et les secrets

Ne pas tout versionner

Certains fichiers ne doivent jamais être suivis par Git : fichiers temporaires, dépendances téléchargées automatiquement, et surtout, fichiers contenant des secrets (mots de passe, clés API, certificats privés).

Le fichier .gitignore

# .gitignore
.env
*.log
node_modules/
__pycache__/
*.pem
secrets.yml

Chaque ligne définit un motif de fichiers ou dossiers que Git doit ignorer : ils n'apparaîtront jamais dans git status ni ne pourront être ajoutés par erreur avec git add ..

Le problème d'un secret déjà commité

Ajouter un fichier au .gitignore après qu'il ait déjà été commité ne le retire pas de l'historique existant. Le secret reste visible dans les anciens commits, consultables par quiconque a accès au dépôt, y compris après suppression du fichier dans un commit ultérieur.

# Retirer un fichier déjà suivi, sans le supprimer du disque
git rm --cached secrets.yml

Cette commande arrête le suivi futur, mais ne nettoie pas l'historique existant : si un vrai secret a fuité, il doit être considéré comme compromis et changé immédiatement, quelle que soit la correction Git appliquée ensuite.

Cas concret

Un développeur commite par erreur un fichier .env contenant une clé API de production, avant de réaliser l'erreur et de l'ajouter au .gitignore dans un commit suivant. La clé reste pourtant visible dans l'historique Git, accessible à quiconque clone le dépôt et consulte git log. La seule action réellement sûre est de révoquer et régénérer cette clé API immédiatement, indépendamment de tout nettoyage ultérieur de l'historique Git (techniquement possible mais complexe et risqué).

Erreurs fréquentes

• Croire qu'ajouter un fichier au .gitignore efface son contenu déjà commité de l'historique : c'est faux, seul le suivi futur est arrêté.
• Ne créer un .gitignore qu'après avoir déjà commité des fichiers sensibles, alors qu'il devrait être configuré dès le premier commit d'un projet.
• Ne pas réagir en révoquant un secret qui a fuité, en pensant qu'un simple nettoyage Git suffit à annuler l'exposition déjà survenue.

À retenir

• Le .gitignore empêche des fichiers d'être suivis, mais ne nettoie jamais un historique où ils ont déjà été commités.
• Un secret commité par erreur doit être révoqué et régénéré immédiatement, quel que soit le nettoyage Git effectué ensuite.
• Configurer le .gitignore dès le premier commit d'un projet évite la majorité de ces incidents.

Mini-exercice

Une clé API de production est commitée par erreur, puis le fichier est ajouté au .gitignore dans un commit suivant. La clé est-elle protégée désormais ?

Réponse : non, elle reste visible dans l'historique Git antérieur, accessible à quiconque consulte les anciens commits. La seule protection réelle est de révoquer et régénérer cette clé API immédiatement, le .gitignore n'empêchant que le suivi futur, pas l'exposition déjà survenue.