Назад до блога

Видалення невідстежуваних файлів у Git: безпечний git clean

9 вересня 2026 р.

TL;DR: щоб видалити невідстежувані файли в git, виконайте git clean -fd — але завжди спершу передивіться через git clean -nd, бо clean видаляє назавжди і до кошика вони не потрапляють ніколи. -f для файлів, -fd для файлів і тек, -fdx, якщо ігноровані артефакти збирання теж мають піти. Найпоширеніша скарга — «git clean не видаляє мої невідстежувані файли» — майже завжди означає, що файли живуть усередині невідстежуваної теки (додайте -d) або вони ігноровані (додайте -x). Невідстежуване безладдя — нормальний побічний продукт експериментів, збирання і скриптів біля клонів; цей гайд показує, як передивлятися кожне видалення, чистити лише одну теку і які комбінації ніколи не запускати в репозиторії, який вам дорогий.

Що означає «невідстежувані файли» в git status?

Невідстежуваний означає: git бачить файл на диску, але йому ніхто не казав його відстежувати — його немає в індексі й немає історії комітів. git status розкладає все на три відра:

$ git status --short
 M src/app.ts        # modified: відстежуваний, змінений
 ?? notes.txt         # untracked: новий файл, git його не знає
 ?? build/            # невідстежувана тека: для git цілком нова

Ця різниця важлива, бо кожне відро чиститься своїм інструментом. Відстежувані-але-змінені файли відкочуються через git restore або в коміт — git clean їх не торкнеться. Лише рядки ?? — територія git clean. Ігноровані файли (усе, що матчить .gitignore) — приховане четверте відро: вони навіть не показуються як ??, і git clean їх пропускає, якщо ви явно не погодитеся через -x.

Якщо ваша справжня проблема — відстежуваний файл, якого не було б комітити, чистка — не той інструмент: це робота git rm --cached або скидання останнього коміта, як у git undo last commit: зі збереженням змін.

Як видалити невідстежувані файли в git?

Ядро — команда git clean -f. Без -f git відмовляється щось видаляти і просто друкує попередження — свідома страховка. Повний ритуал виглядає так:

# 1. Побачте точно, що буде видалено (dry run — нічого не видаляє)
git clean -nd

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

# 2. Переконайтеся, що в списку немає цінного, тоді видаляйте по-справжньому
git clean -fd

Прапорець за прапорцем:

  • -f / --force — обов’язковий. Справді видаляє невідстежувані файли.
  • -d — спускається в невідстежувані теки. Голий -f знімає невідстежувані файли лише на верхньому рівні і звітує теки, які не наважився торкнутися.
  • -n / --dry-run — показати, що б було видалено. Завжди спершу.
  • -x — видаляти також ігноровані файли (node_modules, артефакти збирання, .env).
  • -X — видаляти лише ігноровані, зберігаючи невідстежувані-але-неігноровані.
  • -i — інтерактивний режим; зручний, коли список dry-run довгий.

Звичка, гідна копіювання: поводьтеся з git clean -nd як із git diff — дивитеся перед комітом, дивіться перед чисткою.

Чому git clean не видаляє мої невідстежувані файли?

Три справжні причини за частотою укусу:

1. Файли всередині невідстежуваної теки. З голим -f git прибирає невідстежувані файли вільно лежачі, але зупиняється перед теками — навіть звітує Would remove build/, не видаляючи нічого в справжньому запуску. Додайте -d:

git clean -fd

2. Файли в gitignore. node_modules/, dist/, .venv/ — ігноровані шляхи невидимі для голої чистки. Dry run їх не перелічить, і чистка їх не зніме. Погодьтеся явно:

git clean -fdx   # невідстежувані + ігноровані файли й теки

3. Вкладений git-репозиторій чи submodule стоїть на шляху. Git ніколи не видаляє вміст чужого репозиторію ззовні. Приберіть submodule належним чином або передайте --force двічі (git clean -ffd) — і радше перший варіант.

Якщо dry run не списав нічого, а git status досі показує ?? — ви, найімовірніше, не в тій робочій гілці дерева: виконайте git rev-parse --show-toplevel і перевірте, що ви саме в тому репозиторії, який хотіли чистити.

Як видалити невідстежувані файли лише з конкретної теки?

Обмежте чистку, передавши шлях — решту лишають у спокої:

git clean -fd build/          # лише всередині build/
git clean -fd src/generated   # одне конкретне дерево

Це відповідь на «хочу прибрати невідстежувані файли й теки в build/, але залишити свої нотатки в корені». Шлях відносний до поточної теки: запуск із кореня обмежує всім репозиторієм, із підтеки — цим піддеревом.

Як прибрати невідстежувані файли, не видаляючи їх?

Коли dry run показує файли, які можуть знадобитися, — не грайте в рулетку: спершу збережіть, потім чистіть:

# Сховайте невідстежувані файли (і ігноровані з -a) без видалення
git stash push --include-untracked
git clean -fd                      # дерево чисте
git stash pop                      # поверніть, коли знадобиться

git stash -u виносить невідстежувані файли з дерева, але тримає їх поверта́ними — це та сама семантика «прибрати без видалення», яку люди насправді шукають. А для огляду, який можна лишити собі, git clean -nd > clean-plan.txt дає точний список до будь-яких рішень. Скасування після git clean -f не існує: видалено — означає зникло.

git clean vs git rm vs git restore: що коли?

КомандаТоркаєтьсяВидаляє з дискаКоли
git clean -fdНевідстежувані файли/текиТакВидалити те, чого git не знає
git clean -fdxНевідстежувані + ігнорованіТакПовний скид включно з node_modules та артефактами
git rm <file>Відстежувані файлиТак (застейджено)Видалити файл і записати видалення в git
git rm --cached <file>Відстежувані файлиНіПрипинити відстеження, лишивши файл на диску
git restore <file>Відстежувані файлиНіВідкинути локальні правки, лишивши файл

Правило одним рядком: clean керує тим, чого git не знає; rm і restore — тим, що знає. Плутанина між ними — спосіб, яким люди втрачають роботу: запускаючи git clean -fdx у вірі, що воно поведе себе як git restore.

Чого ніколи не робити з git clean?

Дві звички, яких слід уникати як вогню:

  1. Ніколи не запускайте git clean -fdx бездумно в monorepo чи workspace. Воно видаляє кожну ігноровану теку — це кожен node_modules, кожен virtualenv, кожен локальний .env у дереві. Повернення може коштувати годину перевстановлення, а видалений .env може не повертатися взагалі.
  2. Ніколи не робіть alias із вшитим force. git config alias.wipe "clean -fd" здається ефективним, доки ви не одрукуєте шлях. Тримайте dry run на відстані однієї клавіші (git clean -nd) і зробіть із цього ритуал на дві команди: передивився — видалив.

Корисно знати й це: чистка невідстежуваних файлів просто перед pull з [синхронізації fork з upstream] тримає поверхню мержа маленькою — акуратне дерево найдешевша страховка від конфліктів: синхронізація fork з upstream, крок за кроком.

Безпечний робочий процес git clean, стисло

git status --short        # що в дереві?
git clean -nd             # передпрогляд: що Б пішло?
git clean -fd             # видалити невідстежувані файли + теки
git clean -fdX            # (опційно) прибрати лише ігноровані артефакти
git status --short        # перевірка: робоче дерево чисте

Передпрогляд, видалення, перевірка — тридцять секунд, нуль шкодувань, і git status знову читається як «clean».

— mrsaynothing

— mrsaynothing

Польові нотатки про ШІ, Linux і self-hosting.

Обговорити пост на dev.to dev.to ↗

Наступний гайд — на email

Один лист на пост. Полагодили — і далі.

self-hosted · без третіх сторін · відписка в один клік

що це таке?

rsync чи scp: якою командою копіювати в Linux

Читається добре? Таке я будую за гроші. найміть мене