Supprimer les fichiers non suivis de git : le rituel clean en toute sécurité
Prévisualisez avec -nd, supprimez avec -fd, touchez les fichiers ignorés avec -x — les trois zones de votre arbre de travail, les trois causes du « clean ne supprime rien », et stash -u comme filet.
■ espace · voie de prose
git clean -nd prévisualise, git clean -fd supprime — clean est permanent ; la corbeille n'est jamais impliquée.
Clean ne supprime rien ? Les fichiers sont dans un répertoire non suivi (ajoutez -d)) ou sont ignorés (ajoutez -x).
Vous voulez les récupérer ? git stash -u avant le nettoyage — aucun retour en arrière après -f.
LE PÉRIMÈTRE TOUCHÉ
Chaque fichier de votre arbre vit dans l'une des trois zones — et chaque flag de clean n'atteint qu'un seul cercle :
clean ne les touche jamais. Éditions : git restore. Suppression : git rm.
atteints par clean -f, et par -d dans les répertoires non suivis
atteints uniquement avec -x (ou -X pour les ignorés seuls)
le quatrième compartiment est le piège : les fichiers ignorés n'apparaissent même pas en ?? — un clean simple les saute silencieusement, voilà pourquoi il « ne supprime rien »
CE QUE VEUT DIRE « UNTRACKED »
Non suivi signifie que git voit le fichier sur le disque mais qu'on ne lui a jamais demandé de le suivre — pas dans l'index, pas d'historique de commit. git status regroupe tout en compartiments, et chacun demande un outil de suppression différent :
$ git status --short
M src/app.ts # modified: tracked, changed
?? notes.txt # untracked: new file git doesn't know
?? build/ # untracked directory: entirely new to git
Les fichiers suivis-modifiés se rétablissent avec git restore ou passent en commit — git clean ne les touche pas. Seules les ?? lignes sont le territoire du clean. Si votre vrai problème est un fichier suivi qui n'aurait jamais dû être committé, clean est le mauvais outil — c'est un travail pour git rm --cached, voire un reset du dernier commit.
LE RITUEL
# 1. see exactly what will be deleted (dry run — deletes nothing)
git clean -nd
# Would remove:
# notes.txt
# build/
# 2. confirm nothing precious is in the list, then delete for real
git clean -fd
verify : git clean -nd → affiche « Would remove notes.txt build/ » · après -fd : git status --short ne liste plus aucune ligne ??
Une habitude à copier : traitez git clean -nd comme git diff — vous regardez avant de committer, vous regardez avant de nettoyer. Flag par flag :
-f/--force— obligatoire. Supprime réellement les fichiers non suivis. Sans lui git refuse et imprime un avertissement — un garde-fou délibéré.-d— descendre dans les répertoires. Un-fnu ne retire que les fichiers non suivis du premier niveau et liste les répertoires qu'il a refusé de toucher.-n/--dry-run— montrer ce qui serait supprimé. Toujours en premier.-x— supprimer aussi ignorés fichiers (node_modules, sortie de build,.env).-X— supprimer uniquement les fichiers ignorés, en gardant ceux non suivis mais non ignorés.-i— mode interactif ; pratique quand la liste du dry-run est longue.-e <path>— exclure — « nettoie tout sauf notes.txt » c'estgit clean -fd -e notes.txt.
« CLEAN NE SUPPRIME RIEN » — LES TROIS CAUSES
- Les fichiers sont dans un répertoire non suivi. Avec seulement
-f, git retire les fichiers épars mais s'arrête aux répertoires — en signalant mêmeWould remove build/sans le supprimer dans une vraie exécution.-d:git clean -fd. - Les fichiers sont gitignored.
node_modules/,dist/,.venv/— les chemins ignorés sont invisibles pour un clean simple ; le dry run ne les liste pas non plus. Demandez-les explicitement :git clean -fdx. - Un dépôt git imbriqué ou un sous-module gêne. Git ne supprime jamais le contenu d'un autre dépôt de l'extérieur. Retirez le sous-module proprement ou passez
--forcedeux fois (git clean -ffd) — la première option vaut mieux.
Si le dry run ne liste rien mais que git status montre toujours ?? lignes, vous êtes probablement dans le mauvais arbre de travail — git rev-parse --show-toplevel et vérifiez que vous êtes dans le dépôt que vous comptiez nettoyer.
UN SEUL RÉPERTOIRE À LA FOIS
Cadrer le clean en passant un chemin — tout le reste est laissé tranquille. Le chemin est relatif à votre répertoire courant : depuis la racine du dépôt, ça cadre tout le dépôt ; depuis un sous-répertoire, ce sous-arbre :
git clean -fd build/ # only inside build/
git clean -fd src/generated # one specific tree
RETIRER SANS SUPPRIMER
Quand le dry run montre des fichiers dont vous pourriez avoir besoin plus tard, ne pariez pas — préservez d'abord, nettoyez ensuite. git stash -u déplace les fichiers non suivis hors de l'arbre tout en les gardant récupérables — c'est la sémantique « retirer sans supprimer » que les gens cherchent vraiment :
# stash untracked files (including ignored with -a) without deleting
git stash push --include-untracked
git clean -fd # tree is clean
git stash pop # bring them back when needed
verify : git stash list → stash@{0} contient ce que git stash -u a soulevé
Pour une prévisualisation que vous pouvez garder : git clean -nd > clean-plan.txt. Rien ne se rétablit après git clean -f : supprimé veut dire disparu — la corbeille n'est jamais impliquée.
CLEAN VS RM VS RESTORE
| Commande | Touche | Retire du disque | Quand l'utiliser |
|---|---|---|---|
git clean -fd | Fichiers/répertoires non suivis | Oui | Supprimer des fichiers que git n'a jamais suivis |
git clean -fdx | Non suivi + ignorés | Oui | Reset complet incluant node_modules, sortie de build |
git rm <file> | Fichiers suivis | Oui (indexé) | Supprimer un fichier et consigner la suppression dans git |
git rm --cached <file> | Fichiers suivis | Non | Cesser de suivre un fichier, le garder sur disque |
git restore <file> | Fichiers suivis | Non | Jeter les modifications locales, garder le fichier |
La règle en une ligne : clean gère ce que git ne connaît pas ; rm et restore gèrent ce qu'il connaît. Les confondre, c'est ainsi qu'on perd du travail — lancer git clean -fdx en croyant qu'il se comporte comme git restore.
08CE QU'IL NE FAUT JAMAIS LANCER
- Ne lancez jamais
git clean -fdxà l'aveugle dans un monorepo ou un workspace. Ça supprime chaque répertoire ignoré — chaquenode_modules, chaque virtualenv, chaque.envlocal dans l'arbre..envpeut ne pas être récupérable du tout. - Ne mettez jamais le force en dur dans un alias de clean.
git config alias.wipe "clean -fd"semble efficace jusqu'à ce que vous vous trompiez de chemin. Gardez le dry run à une touche de distance et faites-en un rituel en deux commandes : prévisualiser, puis supprimer.
Le workflow entier, condensé :
git status --short # what's in the tree?
git clean -nd # preview: what WOULD go?
git clean -fd # delete untracked files + directories
git clean -fdX # (optional) clear only ignored build output
git status --short # confirm: working tree clean
Prévisualiser, supprimer, vérifier — trente secondes, zéro regret, et git status se relit enfin propre. Le cousin de ce problème : .gitignore qui semblent ne rien faire — si vos règles sont ignorées, ce sont généralement des fichiers suivis plutôt que de la syntaxe. Et un arbre propre juste avant un fork sync garde la surface de fusion petite — l'assurance contre les conflits la moins chère qui soit.
git status --short ci-dessus a la forme que tout dépôt imprime réellement.fin de la page clean · rien n'a été téléchargé · tout est local