İçeriğe geç
academia.sh

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 .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.

İlerlemeni kaydetmek ve not almak için Giriş yap

Notlarım

Not almak için giriş yapmalısın.

Aramak için yazmaya başlayın.

↑↓ Esc gezin · aç · kapat