Git'te untracked dosyalar nasıl silinir: git clean rehberi // mrsaynothing

TL;DR: git’te untracked dosyaları silmek için git clean -fd çalıştırın — ama önce mutlaka git clean -nd ile önizleyin; çünkü clean kalıcı siler ve dosyalar hiçbir zaman geri dönüşüm kutusuna uğramaz. Dosyalar için -f, dosya ve klasörler için -fd, gitignore’lanmış build çıktısı da gidecekse -fdx kullanın. En sık duyulan şikâyet — “git clean untracked dosyalarımı silmiyor” — neredeyse her zaman dosyaların untracked bir klasörün içinde olması (-d ekleyin) ya da ignored dosyalar olması (-x ekleyin) demektir. Untracked kalabalık, denemelerin, build’lerin ve clone etrafında gezen scriptlerin doğal yan ürünüdür; bu rehber her silmeyi nasıl önizleyeceğinizi, dosyaları yalnızca tek bir klasörden nasıl kaldıracağınızı ve umursadığınız bir repoda hangi kombinasyonları asla çalıştırmamanız gerektiğini gösteriyor.

git status çıktısında “untracked files” ne demek?

Untracked, git’in dosyayı diskte gördüğü ama onu izlemek için hiç söylenmemiş olması demektir — index’te yoktur, commit geçmişi yoktur. git status her şeyi üç gruba ayırır:

$ git status --short
 M src/app.ts        # modified: izleniyor, değişmiş
?? notes.txt         # untracked: git'in haberi olmayan yeni dosya
?? build/            # untracked klasör: git için tamamen yeni

Bu ayrım önemlidir, çünkü her grup farklı bir kaldırma aracı ister. İzlenen ama değişmiş dosyalar git restore ile geri alınır ya da commit’lenip kurtulur — git clean onlara dokunmaz. Yalnızca ?? satırları git clean‘ın alanıdır. Ignored dosyalar (.gitignore ile eşleşen her şey) gizli bir dördüncü gruptur: ?? olarak bile görünmezler ve açıkça -x ile izin vermedikçe git clean onları atlar.

Asıl probleminiz hiç commit’lenmemesi gereken izlenen bir dosyaysa, temizlik yanlış araçtır — o iş ya git rm --cached‘tir ya da git undo last commit: değişiklikleri koruyarak yazısında anlatıldığı gibi son commit’i sıfırlamaktır.

Git’te untracked dosyalar nasıl silinir?

Ana komut git clean -f. -f olmadan git hiçbir şey silmeyi reddeder ve yalnızca bir uyarı basar — bilinçli bir güvenlik korkuluğu. Tam rutin şöyle:

# 1. Nelerin silineceğini tam olarak gör (dry run — hiçbir şey silmez)
git clean -nd

# Silinecekler:
# notes.txt
# build/
# scratch/

# 2. Listede kıymetli bir şey olmadığını doğrula, sonra gerçekten sil
git clean -fd

Bayrak bayrak:

-f / --force — zorunlu. Untracked dosyaları gerçekten siler.
-d — untracked klasörlerin içine gir. Yalın -f, yalnızca en üst seviyedeki untracked dosyaları kaldırır ve dokunmayı reddettiği klasörleri raporlar.
-n / --dry-run — ne silineceğini gösterir. Önce mutlaka bunu çalıştırın.
-x — ignored dosyaları da siler (node_modules, build çıktısı, .env).
-X — yalnızca ignored dosyaları siler; untracked ama ignored olmayanları bırakır.
-i — etkileşimli mod; dry-run listesi uzunken işe yarar.

Kopyalamaya değer bir alışkanlık: git clean -nd‘ye git diff gözüyle bakın — commit’ten önce bakıyorsanız, clean’tan önce de bakın.

git clean untracked dosyalarımı neden silmiyor?

Üç gerçek sebep, başınıza gelme sıklığı sırasıyla:

1. Dosyalar untracked bir klasörün içinde. Yalnızca -f ile git, dağınık untracked dosyaları kaldırır ama klasörlerde durur; gerçek bir çalıştırmada silmediği halde Would remove build/ raporunu vermeyi sürdürür. -d ekleyin:

git clean -fd

2. Dosyalar gitignore’lanmış. node_modules/, dist/, .venv/ — ignored yollar, düz bir clean için görünmezdir. Dry run onları listelemez, clean da silmez. Açıkça izin verin:

git clean -fdx   # untracked + ignored dosya ve klasörler

3. İç içe bir git deposu ya da submodule araya giriyor. Git, başka bir reponun içeriğini dışarıdan asla silmez. Submodule’u düzgünce kaldırın ya da --force‘u iki kez verin (git clean -ffd) — ilki her zaman tercih edilir.

Dry run hiçbir şey listelemiyorsa ama git status hâlâ ?? satırları gösteriyorsa, muhtemelen yanlış working tree’desiniz — git rev-parse --show-toplevel çalıştırın ve temizlemek istediğiniz reponun içinde olduğunuzu doğrulayın.

Untracked dosyaları yalnızca belirli bir klasörden nasıl silerim?

Temizliği bir yol vererek kapsamlandırın — gerisine dokunulmaz:

git clean -fd build/          # yalnızca build/ içinde
git clean -fd src/generated   # tek bir dizin ağacı

Bu, ”build/ içindeki untracked dosya ve klasörler gitsin ama repo kökündeki çalışma notlarım kalsın” sorusunun cevabıdır. Yol, bulunduğunuz dizine göredir: repo kökünden çalıştırırsanız kapsam tüm repo olur, bir alt dizinden çalıştırırsanız o alt ağaç olur.

Untracked dosyaları silmeden nasıl kaldırırım?

Dry run, sonradan lazım olabilecek dosyalar gösteriyorsa kumar oynamayın — önce koru, sonra temizle:

# Untracked dosyaları silmeden stash'le (-a ile ignored olanlar da dahil)
git stash push --include-untracked
git clean -fd                      # ağaç temiz kaldı
git stash pop                      # lazım olduğunda geri getir

git stash -u, untracked dosyaları ağaçtan çıkarır ama kurtarılabilir tutar — insanların aslında aradığı “silmeden kaldır” davranışı budur. Elinizde kalacak bir önizleme için git clean -nd > clean-plan.txt, hiçbir şeye commit atmadan tam listeyi verir. git clean -f sonrasında geri alma yoktur: silindi demek bitti demektir.

git clean vs git rm vs git restore: hangisi ne zaman?

Komut	Neye dokunur	Diskten siler mi	Ne zaman kullanın
`git clean -fd`	Untracked dosya/klasörler	Evet	Git’in hiç izlemediği dosyaları silmek için
`git clean -fdx`	Untracked + ignored	Evet	`node_modules`, build çıktısı dahil tam sıfırlama
`git rm <file>`	İzlenen dosyalar	Evet (stage’li)	Bir dosyayı silmek ve silmeyi git’e kaydettirmek için
`git rm --cached <file>`	İzlenen dosyalar	Hayır	İzlemeyi bırakıp dosyayı diskte tutmak için
`git restore <file>`	İzlenen dosyalar	Hayır	Yerel düzenlemeleri atıp dosyayı korumak için

Tek satırlık kural: clean, git’in haberinin olmadığını yönetir; rm ve restore, haberinin olanı. İşi kaybeden şey, bunları karıştırmaktır — git restore gibi davrandığını sanarken git clean -fdx çalıştırmak gibi.

git clean’ı asla nerede çalıştırmamalısınız?

Hemen bırakılması gereken iki alışkanlık:

Bir monorepo ya da workspace’te git clean -fdx‘i körlemesine asla çalıştırmayın. Ağaçtaki tüm ignored klasörleri siler — her node_modules, her virtualenv, her yerel .env. Geri kazanmak saatlerce yeniden kurulum demektir; silinen bir .env ise hiç kurtarılamayabilir.
Clean’ı, force gömülü şekilde asla alias yapmayın. git config alias.wipe "clean -fd" verimli hissettirir — ta ki yolu yanlış yazana kadar. Dry run’ı tek tuş mesafesinde tutun (git clean -nd) ve iki komutluk bir ritüel edinin: önce önizle, sonra sil.

Şunu da bilmeye değer: [fork'u upstream ile senkronlama] pull’undan hemen önce untracked dosyaları temizlemek, merge yüzeyini küçültür — derli toplu bir ağaç, en ucuz çakışma sigortasıdır: fork’u upstream ile adım adım senkronlama.

Güvenli git clean iş akışı, özetle

git status --short        # ağaçta ne var?
git clean -nd             # önizleme: ne GİDECEKTİ?
git clean -fd             # untracked dosya + klasörleri sil
git clean -fdX            # (isteğe bağlı) yalnızca ignored build çıktısını temizle
git status --short        # doğrula: working tree temiz

Önizle, sil, doğrula — otuz saniye, sıfır pişmanlık ve git status nihayet yine temiz okunuyor.

Git'te untracked dosyalar nasıl silinir: git clean rehberi