.gitignoregénérateur
guide

Ignorer des fichiers déjà commités

Comment arrêter de suivre avec git rm --cached des fichiers toujours visibles après leur ajout au .gitignore, trouver les fichiers suivis qui correspondent aux règles, et quoi faire quand un secret a été commité.

C'est la question la plus fréquente. Le .gitignore ne s'applique qu'aux fichiers qui ne sont pas encore suivis. Un fichier commité une fois continue d'afficher ses modifications même après l'ajout de la règle. Pour arrêter de le suivre, il faut le retirer de l'index (la zone de préparation).

Un fichier ou un dossier

# 1) ajouter la règle au .gitignore (ex. : .env, dist/)
# 2) retirer seulement de l'index — le fichier reste dans le répertoire de travail
git rm --cached .env
git rm -r --cached dist/
# 3) commiter
git commit -m "Stop tracking .env and dist"

L'essentiel est --cached. Sans cette option, git rm supprime aussi le fichier du répertoire de travail. Les répertoires demandent -r.

Trouver les fichiers suivis qui correspondent aux règles

Pour voir ce qui est concerné après l'application d'un nouveau modèle, utilisez la commande suivante.

git ls-files -ci --exclude-standard

-c désigne les fichiers suivis, -i ne garde que ceux qui correspondent à une règle d'exclusion, et --exclude-standard applique le .gitignore, .git/info/exclude et la configuration globale. Si la liste est correcte, vous pouvez tous les retirer du suivi d'un coup.

# bash / zsh
git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached --
# PowerShell
git -c core.quotePath=false ls-files -ci --exclude-standard | ForEach-Object { git rm --cached -- "$_" }

L'onglet Ne plus suivre du générateur construit ces commandes pour votre shell.

Tout réappliquer

Si vous avez beaucoup modifié le .gitignore, on vide aussi souvent l'index avant de tout rajouter.

git rm -r --cached .
git add .
git commit -m "Apply .gitignore"

git add . applique les règles d'exclusion en rajoutant les fichiers : les fichiers ignorés restent donc dehors. Vérifiez toutefois la liste des suppressions avec git status avant de commiter. Dans un dépôt où le réglage des fins de ligne (core.autocrlf) diffère, beaucoup de fichiers peuvent apparaître modifiés.

Conséquences pour les autres

Après le push du commit qui arrête le suivi, le fichier est supprimé du répertoire de travail de toute personne qui récupère ce commit par pull. Du point de vue de git, le fichier a été retiré du dépôt. S'il s'agit d'un fichier dont chacun a besoin, comme .env ou des réglages d'IDE, prévenez à l'avance pour que chacun en fasse une sauvegarde.

Si un secret a déjà été poussé

Arrêter le suivi n'affecte que les commits futurs. Le fichier reste dans les anciens commits et n'importe qui peut le récupérer dans l'historique. L'ordre est le suivant :

  1. Révoquez et régénérez d'abord les clés et mots de passe exposés. C'est le plus important.
  2. Arrêtez le suivi du fichier et ajoutez-le au .gitignore.
  3. Si nécessaire, supprimez le fichier de l'historique avec un outil comme git filter-repo, puis faites un push forcé. Les copies déjà clonées ou forkées ne sont pas effacées : cela ne remplace pas l'étape 1.

assume-unchanged et skip-worktree ne servent pas à ignorer

git update-index --assume-unchanged et --skip-worktree masquent temporairement les modifications d'un fichier suivi, mais le fichier reste suivi.

La documentation de git déconseille elle-même d'utiliser ces options pour ignorer les modifications de fichiers suivis. Pour un fichier de configuration partagé, il est plus sûr de commiter un config.example.json et d'ignorer le vrai config.json.

Références

← PrécédentDes règles d'exclusion personnelles avec .git/info/exclude