git clean : supprimer les fichiers non suivis sans risque

TL;DR : pour supprimer les fichiers non suivis dans git, lance git clean -fd — mais prévisualise toujours avec git clean -nd d'abord, car clean supprime définitivement et rien ne passe par la corbeille. -f pour les fichiers, -fd pour les fichiers et dossiers, -fdx si la sortie de build gitignorée doit partir aussi. La plainte la plus fréquente — « git clean ne supprime pas mes fichiers non suivis » — signifie presque toujours que les fichiers vivent dans un dossier non suivi (ajoute -d) ou que ce sont des fichiers ignorés (ajoute -x). Le fouillis non suivi est le sous-produit normal des expériences, des builds et des scripts de clonage ; ce guide montre comment prévisualiser chaque suppression, ne nettoyer qu'un seul dossier, et quelles combinaisons ne jamais lancer dans un dépôt qui te tient à cœur.

Que veut dire « untracked » dans git status ?

Untracked signifie que git voit le fichier sur disque mais qu'on ne lui a jamais demandé de le suivre — il n'est pas dans l'index et n'a aucun historique de commit. git status range tout dans trois cases :

$ git status --short
 M src/app.ts        # modifié : suivi, changé
?? notes.txt         # non suivi : nouveau fichier inconnu de git
?? build/            # dossier non suivi : entièrement nouveau pour git

La distinction compte parce que chaque case demande un outil de suppression différent. Les fichiers suivis mais modifiés se rétablissent avec git restore ou partent dans un commit — git clean ne les touchera pas. Seules les lignes ?? relèvent de git clean. Les fichiers ignorés (tout ce que matche .gitignore) forment une quatrième case cachée : ils n'apparaissent même pas en ??, et git clean les saute sauf opt-in explicite avec -x.

Si ton vrai problème est un fichier suivi qui n'aurait jamais dû être commité, le nettoyage est le mauvais outil — c'est un job pour git rm --cached, ou un reset du dernier commit comme couvert dans git undo last commit : garder les modifications.

Comment supprimer tous les fichiers et dossiers non suivis dans git ?

La commande de base est git clean -f. Sans -f, git refuse de supprimer quoi que ce soit et se contente d'un avertissement — une barrière de sécurité délibérée. La routine complète :

# 1. Voir exactement ce qui sera supprimé (dry run — ne supprime rien)
git clean -nd

# Would remove:
# notes.txt
# build/
# scratch/

# 2. Confirmer que rien de précieux n'est dans la liste, puis supprimer pour de vrai
git clean -fd

Option par option :

-f / --force — obligatoire. Supprime réellement les fichiers non suivis.
-d — descend dans les dossiers non suivis. Un -f seul ne retire que les fichiers non suivis au premier niveau et signale les dossiers qu'il a refusé de toucher.
-n / --dry-run — montre ce qui serait supprimé. À lancer toujours en premier.
-x — supprime aussi les fichiers ignorés (node_modules, sortie de build, .env).
-X — ne supprime que les fichiers ignorés, en gardant les non-suivis-non-ignorés.
-i — mode interactif ; utile quand la liste du dry-run est longue.

Une habitude à copier : traite git clean -nd comme git diff — tu regardes avant de commiter, tu regardes avant de nettoyer.

Pourquoi git clean ne supprime-t-il rien ?

Trois causes réelles, par fréquence à laquelle elles mordent :

1. Les fichiers sont dans un dossier non suivi. Avec -f seul, git retire les fichiers non suivis éparpillés mais s'arrête aux dossiers, allant jusqu'à annoncer Would remove build/ sans le supprimer lors d'une vraie exécution. Ajoute -d :

git clean -fd

2. Les fichiers sont gitignorés. node_modules/, dist/, .venv/ — les chemins ignorés sont invisibles pour un clean simple. Le dry run ne les liste pas, et le clean ne les retire pas non plus. Opte explicitement :

git clean -fdx   # fichiers et dossiers non suivis + ignorés

3. Un dépôt git imbriqué ou un submodule bloque. Git ne supprime jamais le contenu d'un autre dépôt de l'extérieur. Retire le submodule proprement, ou passe --force deux fois (git clean -ffd) — et préfère la première option.

Si le dry run ne liste rien mais que git status montre encore des ??, tu es probablement dans le mauvais working tree — lance git rev-parse --show-toplevel et vérifie que tu es bien dans le dépôt que tu voulais nettoyer.

Comment ne supprimer les fichiers non suivis que dans un dossier précis ?

Cadre le clean en passant un chemin — tout le reste est laissé tranquille :

git clean -fd build/          # uniquement dans build/
git clean -fd src/generated   # une arborescence précise

C'est la réponse à « je veux retirer les fichiers et dossiers non suivis de build/ mais garder mes notes de brouillon à la racine du dépôt ». Le chemin est relatif à ton dossier courant : lancé depuis la racine, il couvre tout le dépôt ; lancé depuis un sous-dossier, il se limite à cette sous-arborescence.

Comment retirer les fichiers non suivis sans les supprimer ?

Quand le dry run montre des fichiers que tu voudras peut-être plus tard, ne joue pas au casino — préserve d'abord, nettoie ensuite :

# Stash des fichiers non suivis (ignorés inclus avec -a) sans les supprimer
git stash push --include-untracked
git clean -fd                      # l'arbre est propre
git stash pop                      # les récupérer quand besoin

git stash -u sort les fichiers non suivis de l'arbre tout en les gardant récupérables — c'est la sémantique « supprimer sans perdre » que les gens cherchent vraiment. Pour une prévisualisation que tu peux garder, git clean -nd > clean-plan.txt te donne la liste exacte avant de t'engager. Il n'y a pas d'undo après git clean -f : supprimé signifie disparu.

git clean vs git rm vs git restore : lequel, quand ?

Commande	Touche	Retire du disque	À utiliser quand
`git clean -fd`	Fichiers/dossiers non suivis	Oui	Supprimer des fichiers que git n'a jamais suivis
`git clean -fdx`	Non suivis + ignorés	Oui	Reset complet, `node_modules` et sortie de build compris
`git rm <file>`	Fichiers suivis	Oui (stagé)	Supprimer un fichier et enregistrer 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 comme ça qu'on perd du travail — en lançant git clean -fdx en croyant avoir affaire à git restore.

Sur quoi ne jamais lancer git clean ?

Deux habitudes à bannir sans discussion :

Ne lance jamais git clean -fdx à l'aveugle dans un monorepo ou un workspace. Il supprime tous les dossiers ignorés — c'est-à-dire chaque node_modules, chaque virtualenv, chaque .env local de l'arbre. Les récupérer peut coûter une heure de réinstallation, et un .env supprimé peut être irrécupérable tout court.
Ne crée jamais un alias de clean avec le force pré-cuit. git config alias.wipe "clean -fd" paraît efficace jusqu'à la faute de frappe sur le chemin. Garde le dry run à une frappe (git clean -nd) et fais-en un rituel en deux commandes : prévisualiser, puis supprimer.

À savoir aussi : nettoyer les fichiers non suivis juste avant un pull de type [sync a fork with upstream] réduit la surface de merge — un arbre propre est la moins chère des assurances conflit : synchroniser un fork avec upstream, pas à pas.

Le workflow git clean sûr, en résumé

git status --short        # qu'y a-t-il dans l'arbre ?
git clean -nd             # prévisualisation : qu'est-ce qui PARTIRAIT ?
git clean -fd             # supprime fichiers + dossiers non suivis
git clean -fdX            # (optionnel) purge uniquement la sortie de build ignorée
git status --short        # vérification : working tree propre

Prévisualiser, supprimer, vérifier — trente secondes, zéro regret, et git status affiche enfin propre.