Git: jak bezpiecznie usunąć nieśledzone pliki (git clean) // mrsaynothing

TL;DR: nieśledzone pliki usuniesz komendą git clean -fd, ale zawsze najpierw podejrzyj wynik git clean -nd — clean kasuje bezpowrotnie i nic nie trafia do kosza. -f dla plików, -fd dla plików i katalogów, -fdx, jeśli mają zniknąć też wyniki builda z .gitignore. Najczęstsza skarga świata — „git clean nie usuwa moich nieśledzonych plików” — prawie zawsze znaczy, że pliki leżą w nieśledzonym katalogu (dorzuć -d) albo są ignorowane (dorzuć -x). Śmieci nieśledzone to normalny produkt uboczny eksperymentów, buildów i skryptów-klonów; ten przewodnik pokazuje, jak podejrzeć każde usunięcie przedtem, jak posprzątać tylko jeden katalog i których kombinacji nigdy nie odpalać w repo, o które ci chodzi.

Co oznaczają „untracked files” w git status?

Untracked znaczy, że git widzi plik na dysku, ale nikt nigdy nie kazał mu go śledzić — nie ma go w indeksie i nie ma historii commitów. git status grupuje wszystko w trzy kubełki:

$ git status --short
 M src/app.ts        # zmodyfikowany: śledzony, zmieniony
?? notes.txt         # nieśledzony: nowy plik, którego git nie zna
?? build/            # nieśledzony katalog: dla gita całkiem nowy

To rozróżnienie ma znaczenie, bo każdy kubełek wymaga innego narzędzia do sprzątania. Pliki śledzone-zmienione cofasz przez git restore albo po prostu commitujesz — git clean ich nie ruszy. Terytorium git clean to wyłącznie linie z ??. Pliki ignorowane (wszystko, co łapie .gitignore) to ukryty czwarty kubełek: nawet nie pokazują się jako ??, a git clean je pomija, dopóki jawnie nie wejdziesz w to flagą -x.

Jeśli twoim prawdziwym problemem jest śledzony plik, który nigdy nie powinien trafić do repo, sprzątanie to złe narzędzie — to zadanie dla git rm --cached albo resetu ostatniego commita, jak opisuje git undo last commit: jak zachować zmiany.

Jak usunąć nieśledzone pliki w git?

Podstawowa komenda to git clean -f. Bez -f git odmawia usunięcia czegokolwiek i tylko wypisuje ostrzeżenie — celowa szyna bezpieczeństwa. Pełna rutyna wygląda tak:

# 1. Zobacz dokładnie, co zostanie usunięte (dry run — nic nie kasuje)
git clean -nd

# Usunęłoby:
# notes.txt
# build/
# scratch/

# 2. Sprawdź, że na liście nie ma nic cennego, potem kasuj na serio
git clean -fd

Flaga po fladze:

-f / --force — wymagana. Faktycznie usuwa nieśledzone pliki.
-d — wchodzi do nieśledzonych katalogów. Sam -f usuwa tylko nieśledzone pliki z samej góry i wypisuje katalogi, których dotknąć odmówił.
-n / --dry-run — pokazuje, co zostałoby usunięte. Zawsze odpalaj to najpierw.
-x — kasuje też pliki ignorowane (node_modules, wyniki builda, .env).
-X — kasuje wyłącznie pliki ignorowane, zostawiając nieśledzone-nieignorowane.
-i — tryb interaktywny; przydaje się, gdy lista z dry-runa jest długa.

Nawyk wart podkradzenia: traktuj git clean -nd jak git diff — patrzysz przed commitem, patrzysz przed sprzątaniem.

Czemu git clean nie usuwa moich nieśledzonych plików?

Trzy prawdziwe przyczyny, w kolejności od najczęstszej:

1. Pliki leżą wewnątrz nieśledzonego katalogu. Samym -f git usuwa luźne nieśledzone pliki, ale na katalogach się zatrzymuje — potrafi wypisać Would remove build/ i przy realnym uruchomieniu nic nie skasować. Dorzuć -d:

git clean -fd

2. Pliki są zignorowane w .gitignore. node_modules/, dist/, .venv/ — ignorowane ścieżki są niewidoczne dla zwykłego cleana. Dry run ich nie wypisze, a clean ich nie usunie. Wejdź w to jawnie:

git clean -fdx   # nieśledzone + ignorowane pliki i katalogi

3. Po drodze stoi zagnieżdżone repo gita albo submodule. Git nigdy nie kasuje zawartości cudzego repo z zewnątrz. Usuń submodule porządnie albo podaj --force dwa razy (git clean -ffd) — i wybieraj tę pierwszą opcję.

Jeśli dry run nie wypisuje nic, a git status dalej pokazuje ??, to pewnie jesteś w złym drzewie roboczym — odpal git rev-parse --show-toplevel i sprawdź, że siedzisz w repo, które zamierzałeś posprzątać.

Jak usunąć nieśledzone pliki tylko z jednego katalogu?

Ogranicz zakres, podając ścieżkę — reszta zostaje nietknięta:

git clean -fd build/          # tylko w środku build/
git clean -fd src/generated   # jedno konkretne drzewo

To odpowiedź na „chcę wyczyścić nieśledzone pliki i foldery w build/, ale zachować swoje notatki w korzeniu repo”. Ścieżka jest względna wobec katalogu bieżącego, więc start z korzenia obejmuje całe repo, a start z podkatalogu — tylko to poddrzewo.

Jak pozbyć się nieśledzonych plików, nie usuwając ich?

Gdy dry run pokazuje pliki, które mogą się jeszcze przydać, nie graj w totka — najpierw zabezpiecz, potem sprzątaj:

# Zstashuj nieśledzone pliki (ignorowane dołączy -a) bez usuwania
git stash push --include-untracked
git clean -fd                      # drzewo czyste
git stash pop                      # przywróć, gdy będą potrzebne

git stash -u wynosi nieśledzone pliki z drzewa, ale zostawia je odzyskiwalne — to właśnie jest sens „usuń bez usuwania”, którego ludzie właściwie szukają. A jeśli chcesz podgląd do zachowania, git clean -nd > clean-plan.txt da ci dokładną listę, zanim cokolwiek zdecydujesz. Po git clean -f nie ma undo: usunięte znaczy zniknięte.

git clean vs git rm vs git restore: co kiedy?

Komenda	Dotyka	Usuwa z dysku	Kiedy użyć
`git clean -fd`	Nieśledzone pliki/katalogi	Tak	Usuń pliki, których git nigdy nie śledził
`git clean -fdx`	Nieśledzone + ignorowane	Tak	Pełny reset razem z `node_modules` i wynikami builda
`git rm <file>`	Pliki śledzone	Tak (stage’owane)	Usuń plik i zapisz usunięcie w gicie
`git rm --cached <file>`	Pliki śledzone	Nie	Przestań śledzić plik, zostaw go na dysku
`git restore <file>`	Pliki śledzone	Nie	Odrzuć lokalne edycje, zostaw plik

Zasada w jednym zdaniu: clean zarządza tym, o czym git nie wie; rm i restore — tym, o czym wie. Pomieszanie ich to sposób, w jaki ludzie gubią pracę — na przykład odpalając git clean -fdx w przekonaniu, że działa jak git restore.

Na czym nigdy nie odpalać git clean?

Dwa nawyki do wyeliminowania w zarodku:

Nigdy nie odpalaj git clean -fdx na ślepo w monorepo ani workspace. Kasuje każdy ignorowany katalog — czyli każde node_modules, każdy virtualenv, każdy lokalny .env w drzewie. Odzyskanie tego potrafi oznaczać godzinę reinstalacji, a skasowanego .env może nie dać się odzyskać wcale.
Nigdy nie aliasuj cleana z wbudowanym force. git config alias.wipe "clean -fd" wydaje się sprytne, dopóki literówka w ścieżce. Trzymaj dry run na wyciągnięcie jednego klawisza (git clean -nd) i rytuał dwóch komend: najpierw podgląd, potem kasowanie.

Przy okazji: sprzątnięcie nieśledzonych plików tuż przed purllem synchronizującym fork z upstream zmniejsza powierzchnię merge — czyste drzewo to najtańsze ubezpieczenie od konfliktów: synchronizacja forka z upstreamem, krok po kroku.

Bezpieczny workflow git clean w pigułce

git status --short        # co jest w drzewie?
git clean -nd             # podgląd: co zostałoby usunięte?
git clean -fd             # usuń nieśledzone pliki + katalogi
git clean -fdX            # (opcjonalnie) wyczyść tylko ignorowane wyniki builda
git status --short        # potwierdzenie: drzewo robocze czyste

Podgląd, usunięcie, weryfikacja — trzydzieści sekund, zero żalu i git status wreszcie znowu jest czysty.

Git: jak bezpiecznie usunąć nieśledzone pliki (git clean)