■ espace · voie de prose

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 :

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 -f nu 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'est git clean -fd -e notes.txt.

« CLEAN NE SUPPRIME RIEN » — LES TROIS CAUSES

1. 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ême Would remove build/ sans le supprimer dans une vraie exécution.-d: git clean -fd.
2. 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.
3. 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 --force deux 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

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

1. Ne lancez jamais git clean -fdx à l'aveugle dans un monorepo ou un workspace. Ça supprime chaque répertoire ignoré — chaque node_modules, chaque virtualenv, chaque .env local dans l'arbre..env peut ne pas être récupérable du tout.
2. 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.

fin de la page clean · rien n'a été téléchargé · tout est local