Ders 09 / 15
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.
İçindekiler
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:
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 *~
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.
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:
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:
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:
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:
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:
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.
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:
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
.gitignoredosyası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 --cachedile 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.
İlerlemeni kaydetmek ve not almak için Giriş yap
Notlarım
Not almak için giriş yapmalısın.