--- title: 'Yoksayma Kuralları' source: 'https://academia.sh/tr/kurslar/surum-kontrolune-giris/yoksayma-kurallari' course: 'Sürüm Kontrolüne Giriş' language: tr updated: '2026-08-17T18:10:47+00:00' license: 'CC BY-SA 4.0' --- # Yoksayma Kuralları Depoya girmemesi gereken dosyalar, `.gitignore` kalıp söz dizimi, kuralın kaynağını bulma ve yoksayma kurallarının izlenen dosyalara neden işlemediği. Depoda şimdiye kadar yalnızca elle yazılan dosyalar bulunuyor. Oysa çalışırken üretilen dosyalar da oluşur: betiğin çıktısı, düzenleyicinin bıraktığı yedekler, derleme sonuçları. Bunlar her `git status` çağrısında listelenerek gerçek değişikliklerin görünürlüğünü düşürür ve yanlışlıkla işlemeye girebilir. Bu ders, hangi dosyaların depodan uzak tutulacağını ve bu kararın nasıl kaydedileceğini ele alır. ## Depoya Girmemesi Gerekenler Dört sınıf ayrılır: - **Türetilmiş dosyalar.** Depodaki kaynaklardan üretilebilen her şey: derleme çıktıları, betiklerin ürettiği veriler, geçici raporlar. Tarihçede tutulmaları gereksizdir, çünkü kaynaktan yeniden üretilebilirler; üstelik her üretimde değiştikleri için sürekli fark gösterirler. - **Yerel ortam dosyaları.** Düzenleyici ayarları, işletim sisteminin dizinlere bıraktığı üstveri dosyaları, kişisel notlar. Bunlar projeye değil kişiye aittir. - **Gizli bilgiler.** Parolalar, erişim anahtarları, özel sertifikalar. Bunların depoya girmemesi bir düzen sorunu değil, güvenlik gereğidir. - **Büyük ikili dosyalar.** Her sürümü ayrı bir nesne olarak saklanır ve fark alınamadığı için sıkıştırılamaz. Deponun tüm kopyalarında yer kaplarlar. Üçüncü madde ayrı bir uyarı gerektirir. Önceki konuda belirtildiği gibi, dağıtık bir depoda tarihçe her kopyaya yayılır. Bir parola işlendikten sonra silinse bile silme işlemi yalnızca yeni bir işleme ekler; parolayı içeren eski işleme yerinde durur ve deponun her kopyasında bulunur. Bu durumda tek doğru davranış, gizli bilginin geçersiz kılınmasıdır. ## `.gitignore` Dosyası Örnek depoda betik çalıştırıldığında bir günlük dosyası ve bir çıktı dizini oluşur; düzenleyici de bir yedek bırakır: ```bash git status --short ``` ``` ?? README.md~ ?? ara.log ?? cikti/ ``` Kurallar `.gitignore` adlı bir metin dosyasına yazılır: ``` # Betiğin ürettiği çıktılar ara.log cikti/ # Düzenleyici yedekleri *~ ``` ```bash git status --short ``` ``` ?? .gitignore ``` Üç girdi listeden çıktı; geriye kuralları taşıyan dosyanın kendisi kaldı. `.gitignore` depoya işlenir: kurallar projeye aittir ve deponun her kopyasında aynı olmalıdır. ```bash git add .gitignore git commit -m "Üretilen dosyaları yoksayma listesine al" ``` ``` [main 9b23cc3] Üretilen dosyaları yoksayma listesine al 1 file changed, 6 insertions(+) create mode 100644 .gitignore ``` ## Kalıp Söz Dizimi Her satır bir **kalıptır (pattern)**: yol adlarıyla eşleştirilen, joker karakterler içerebilen bir dizgi. | Kalıp | Anlamı | |---|---| | `*.log` | Uzantısı `.log` olan dosyalar, her derinlikte | | `cikti/` | Yalnızca `cikti` adlı dizinler ve içerikleri | | `/gecici.tmp` | Yalnızca depo kökündeki `gecici.tmp` | | `not?.txt` | Tek karakter joker: `not1.txt`, `not2.txt` | | `a/**/veri.bin` | `a` altında herhangi bir derinlikteki `veri.bin` | | `!ara.log` | Önceki bir kuralın kapsadığı dosyayı kural dışı bırakır | | `# metin` | Açıklama satırı | İki ayrıntı sık karıştırılır. Birincisi **eğik çizginin konumu**: kalıbın içinde ya da başında eğik çizgi varsa kalıp `.gitignore` dosyasının bulunduğu dizine göre çözülür; yoksa her derinlikte eşleşir. `/gecici.tmp` yalnızca kökteki dosyayı yakalar, `alt/gecici.tmp` dosyasını yakalamaz. İkincisi **sondaki eğik çizgi**: `cikti/` yalnızca dizinlerle eşleşir, `cikti` adlı bir dosyayla eşleşmez. Kurallar sırayla değerlendirilir ve **son eşleşen kural** geçerlidir. Bu nedenle `!` ile başlayan kural, kapsadığı kalıptan sonra yazılmalıdır; önce yazılırsa etkisiz kalır. ## Bir Dosya Neden Yoksayılıyor Uzun kural listelerinde hangi satırın etkili olduğu doğrudan sorulur: ```bash git check-ignore -v ara.log cikti/son-arama.txt "README.md~" ``` ``` .gitignore:2:ara.log ara.log .gitignore:3:cikti/ cikti/son-arama.txt .gitignore:6:*~ README.md~ ``` Her satır kuralın bulunduğu dosyayı, satır numarasını, kalıbı ve eşleşen yolu verir. `!` ile başlayan bir kural eşleşiyorsa o da listelenir; bu durumda dosya yoksayılmıyor demektir, çünkü son eşleşen kural onu kural dışı bırakmıştır. Yoksayılan dosyaların tamamı da listelenebilir: ```bash git status --short --ignored ``` ``` ?? .gitignore !! README.md~ !! ara.log !! cikti/ ``` `!!` işareti yoksayılan girdileri belirtir. ## Yoksayma İzlenen Dosyalara İşlemez Yerel notların tutulduğu bir dosya yanlışlıkla işlenir: ```bash git commit -m "Yerel notları ekle" ``` ``` [main 7783378] Yerel notları ekle 1 file changed, 3 insertions(+) create mode 100644 notlar-yerel.md ``` Hata fark edilir ve dosya adı `.gitignore` dosyasına eklenir. Ancak durum değişmez: ```bash git ls-files ``` ``` .gitignore README.md ara.sh notlar-yerel.md terimler.txt ``` Dosya hâlâ izleniyor. Kuralın işlememesi bir kusur değil, tanımın sonucudur: yoksayma kuralları **izlenmeyen** dosyaların listelenip listelenmeyeceğini belirler. Bir dosya hazırlık alanında kayıtlıysa artık izlenmektedir ve kurallar onu ilgilendirmez. Aksi hâlde bir kural eklemek, izlenen dosyaların sessizce tarihçeden düşmesine yol açardı. Aynı nedenle `git check-ignore` de sessiz kalır: komut varsayılan olarak izlenen yolları değerlendirmez. Çözüm, dosyayı hazırlık alanından çıkarmaktır: ```bash git rm --cached notlar-yerel.md ``` ``` rm 'notlar-yerel.md' ``` `--cached` seçeneği yalnızca hazırlık alanındaki kaydı siler; çalışma dizinindeki dosya yerinde kalır. Seçenek yazılmazsa dosya diskten de silinir. ```bash git commit -a -m "Yerel notları izlemeden çıkar" ``` ``` [main cb8f7ee] Yerel notları izlemeden çıkar 2 files changed, 1 insertion(+), 3 deletions(-) delete mode 100644 notlar-yerel.md ``` Bu işlemeden sonra dosya izlenmiyor ve `.gitignore` kuralı devreye giriyor. Dosyanın eski içeriği ise tarihçede duruyor: `7783378` işlemesi hâlâ erişilebilir. Yoksayma, geçmişi temizlemez; yalnızca bundan sonrasını düzenler. ## Üç Yoksayma Katmanı | Yer | Kapsam | Paylaşılır mı | |---|---|---| | `.gitignore` | Bulunduğu dizin ve altı | Evet, depoya işlenir | | `.git/info/exclude` | Yalnızca bu depo | Hayır, yerelde kalır | | `core.excludesFile` ile gösterilen dosya | Kullanıcının tüm depoları | Hayır | Ayrım şu ölçütle yapılır: kural **projeye** mi yoksa **çalışma alışkanlığına** mı aittir? Derleme çıktısının adı projeye aittir ve `.gitignore` dosyasına yazılır. Kullanılan düzenleyicinin bıraktığı geçici dosyalar kişiye aittir; bunları her projenin `.gitignore` dosyasına eklemek yerine kullanıcı düzeyindeki dosyaya yazmak doğru olanıdır. Depoya özel ama paylaşılmayacak kurallar `.git/info/exclude` dosyasına yazılır ve aynı söz dizimini kullanır: ```bash git check-ignore -v deneme-1.txt ``` ``` .git/info/exclude:7:deneme-*.txt deneme-1.txt ``` Çıktının ilk alanı kuralın hangi dosyadan geldiğini gösterdiği için, üç katman arasındaki karışıklık aynı komutla çözülür. ## Özet - Türetilmiş dosyalar, yerel ortam dosyaları, gizli bilgiler ve büyük ikili dosyalar depoya girmemelidir. - Kurallar `.gitignore` dosyasına yazılır; dosya depoya işlenir ve tüm kopyalarda geçerlidir. - Kalıplarda eğik çizginin konumu kapsamı belirler; sondaki eğik çizgi kalıbı dizinlerle sınırlar; son eşleşen kural geçerlidir. - Yoksayma kuralları yalnızca izlenmeyen dosyaları etkiler; izlenen bir dosya `git rm --cached` ile izlemeden çıkarılmalıdır. - Kurallar üç katmanda tutulabilir: depoya işlenen, depoya özel yerel ve kullanıcı düzeyindeki dosyalar. ## Sonraki Adım Temel döngü tamamlandı: değişiklik yapılıyor, hazırlık alanına alınıyor, işleniyor, tarihçe okunuyor. Ancak bu döngü tek yönlü anlatıldı. Yanlış bir dosya hazırlık alanına alındığında, bir düzenleme geri istendiğinde ya da bir işleme hatalı yazıldığında ne yapılır? Sonraki konu geri alma araçlarını ele alıyor ve ilk ders en dar kapsamlı olanlarla — hazırlıktan çıkarma ve dosya geri yükleme — başlıyor.