Git’in takip ettiği dosyaları .gitignore’dan temizleyen araç: gitslip

.gitignore dosyasına eklenen bir dosya adı, Git’in zaten takip ettiği bir dosyayı etkilemez. Üç hafta önce .env dosyasını .gitignore listesine eklediğinizi düşünün — fakat o dosya GitHub’daki depoda hâlâ duruyor, her klonlama işleminde de indiriliyor. Bu durum aslında bir hata değil; Git’in resmi dokümantasyonunda da belirtildiği gibi .gitignore, yalnızca takip edilmeyen dosyaları eklemekten alıkoyar. Eğer bir dosya daha önceden commit edilmişse, .gitignore kuralı ne olursa olsun takip edilmeye devam eder. Bu da gizli anahtarlar, derleme kalıntıları ve 40 MB’lık log dosyalarının halen depoda bulunmasına neden olur.

Çözüm basit: git rm --cached komutunu çalıştırmak. Ancak sorun şu ki, bu dosyalar genellikle gözden kaçırılır. Çünkü git status çıktısında her şey temiz görünür ve dosya sanki yokmuş gibi görünür.

İşte tam da bu noktada gitslip devreye giriyor. Bu araç, sıfır bağımlılıkla çalışan bir komut satırı aracı olarak tasarlandı. Git’in takip ettiği ancak .gitignore kurallarına göre dışlanması gereken tüm dosyaları bulur ve size doğrudan düzeltme komutlarını sunar.

npx gitslip

Çıktı örneği:

2 takip edilen dosya, kurallarınıza göre dışlanmış durumda:
config/secrets.env
→ .gitignore:7 *.env

logs/app.log
→ .gitignore:2 *.log

Düzeltme — bu dosyaların takibini bırak (yerel kopyaları silinmez):

git rm --cached -- config/secrets.env
git rm --cached -- logs/app.log

Veya gitslip’in otomatik olarak düzeltmesini sağlayın:

gitslip --apply

Araç, her dosya için hangi .gitignore kuralının işe yaradığını gösterir (örneğin .gitignore:7 *.env). Böylece tahminde bulunmanıza gerek kalmaz. Ayrıca --apply seçeneği, git rm --cached komutunu otomatik olarak çalıştırır — bu sadece dosyaların takibini bırakır, yerel kopyalarınızı silmez.

Neden basit bir grep kullanmıyorsunuz?

Evet, .gitignore dosyanızı grep komutuyla tarayabilir ve git ls-files çıktısıyla karşılaştırabilirsiniz. Ancak bu yöntem bazı önemli eksikliklere sahiptir:

• Basit bir grep '\.env' komutu, hâlâ takip edilen bir dosyayı dışlanmış bir dosyadan ayırt edemez.
• Negasyon kuralları (!negation), build/ dizin kuralları, iç içe .gitignore dosyaları, .git/info/exclude veya global core.excludesFile gibi durumları dikkate alamaz.
• Git’in .gitignore eşleştirme mantığını yeniden uygulamak, hassas verilerinizi korumak için kullanacağınız koddan kaçınmanız gereken bir durumdur.

gitslip ise hiçbir şeyi yeniden uygulamaz. Tüm işi Git’e bırakır.

Nasıl çalışır? (İşin eğlenceli kısmı)

Tespit işlemi tek bir Git komutuyla gerçekleşir:

git ls-files -i -c --exclude-standard

• -c: Takip edilen (cached) dosyaları gösterir.
• -i: Dışlanan dosyaları gösterir.
• --exclude-standard: Tüm standart dışlama kaynaklarını kullanır (.gitignore, .git/info/exclude, global core.excludesFile vb.).

Bu komut, Git’in kendi kurallarına göre hem takip edilen hem de dışlanan dosyaların listesini verir. Bu şekilde, negasyon kuralları, dizin yapıları ve yerleşik .gitignore dosyaları doğru bir şekilde işlenir. Kendi eşleştirme mantığınızı uygulamak zorunda kalmazsınız — bu da Git’in davranışıyla herhangi bir uyumsuzluk yaşama riskini ortadan kaldırır.

Peki her bir dosya için hangi kuralın işe yaradığını nasıl adlandırıyoruz? İlk bakışta git check-ignore -v aracı mantıklı görünüyor. Ancak bu araç, bir dosya zaten takip ediliyorsa "dışlanmadı" şeklinde yanıt verir ve ilgili kuralı adlandırmaktan kaçınır. (Ayrıca --no-index seçeneği de test ettiğim Git sürümlerinde her zaman güvenilir çalışmadı.)

İşte sihir burada devreye giriyor: boş bir indeks dosyası kullanarak git check-ignore komutunu çalıştırıyoruz.

GIT_INDEX_FILE=/tmp/empty git check-ignore -v -z --stdin

GIT_INDEX_FILE değişkenini var olmayan bir yola (/tmp/empty) yönlendirdiğimizde, Git bunu boş bir indeks olarak kabul eder. Bu sayede hiçbir dosya takip edilmiyor gibi davranılır ve check-ignore komutu her yol için ilgili .gitignore:line:pattern kuralını adlandırmaktan kaçınmaz. Bu işlem salt okunurdur ve dosya hiçbir zaman oluşturulmaz.

Kurulum

gitslip’i kullanmak için iki farklı yol mevcut:

npx gitslip  # Node.js versiyonu, sıfır bağımlılık

veya

pip install gitslip  # Python versiyonu, sıfır bağımlılık — çıktılar byte seviyesinde aynıdır

Her iki versiyon da sadece standart kütüphaneleri kullanır. Node.js ve Python versiyonları, çıktılarındaki her bir byte’a kadar aynı sonuçları üretir (bu doğrulama CI sürecinde otomatik olarak yapılır).

Ayrıca CI ortamlarında da kullanılabilir. Araç, eğer herhangi bir dosya dışlanması gerekiyorken takip ediliyorsa çıkış kodunu 1 olarak belirler. Bu sayede bir dosya yanlışlıkla commit edilmeden önce build işlemini durdurabilirsiniz:

- name: gitslip ile kontrol
  run: npx gitslip

Şimdi deneyin

Hemen mevcut projenizde npx gitslip komutunu çalıştırın. Eğer daha önce .gitignore dosyası yazmadan git add -A komutunu çalıştırdıysanız, büyük olasılıkla bir şeylerin hâlâ takip edildiğini göreceksiniz.

Peki siz hangi dosyaları silinmesi gerektiğini buldunuz? Bir gizli anahtar, 100 MB’lık bir ikili dosya ya da 2019 yılından kalma bir .DS_Store dosyası mı? Deneyimlerinizi aşağıda paylaşın.