gitignore Kullanımı: Dosya Dışlama ve Şablonlar

Bir .gitignore dosyası, Git'e hangi dosyaları görmezden gelmesi gerektiğini söyler; doğru gitignore kullanımı, repoyu derleme çıktıları, gizli anahtarlar ve editör artıklarıyla şişmekten korur. node_modules/, vendor/, .env ya da .DS_Store gibi dosyalar sürüm geçmişine girdiğinde hem repo gereksiz büyür hem de bir gün yanlışlıkla birinin parolasını yayınlarsın. Bu yazıda dosyaları dışlamanın doğru yolunu, kalıp sözdizimini ve sık yapılan hataları anlatıyorum.

Önemli bir kural baştan: .gitignore sadece henüz takip edilmeyen (untracked) dosyalar için çalışır. Bir dosyayı bir kez commit'ledikten sonra ignore listesine eklemek onu otomatik olarak çıkarmaz — bu en sık karşılaşılan kafa karışıklığıdır ve sonunda ayrı bir başlık ayırdım.

.gitignore dosyası nereye konur?

Çoğu projede tek bir .gitignore dosyası deponun kök dizininde yaşar ve kendisi de commit edilir; böylece tüm ekip aynı kuralları paylaşır. Ama Git birden fazla katmanı destekler:

• Kök .gitignore — projenin tamamı için ortak kurallar; versiyon kontrolüne dahil edilir.
• Alt dizin .gitignore — herhangi bir klasöre koyduğun ek dosya, sadece o klasör ve altındakileri etkiler. Yollar o dizine görelidir.
• .git/info/exclude — yalnızca senin makinendeki kurallar; commit edilmez, paylaşılmaz.
• Global gitignore — tüm depolarına uygulanan kişisel kurallar (aşağıda).

Daha derindeki ve sonra okunan dosyalar, üsttekileri ezebilir. Yani bir alt klasördeki .gitignore, kökteki bir kuralı bir negasyonla geri açabilir.

Kalıp (pattern) sözdizimi

Her satır bir kalıptır. Boş satırlar yok sayılır, # ile başlayan satırlar yorumdur. Temel kurallar şöyle:

# Yorum satırı
*.log              # tüm .log dosyaları (her dizinde)
build/             # sondaki / yalnızca dizinlerle eşleşir
/config.local      # baştaki / kalıbı repo köküne sabitler
temp?.txt          # ? tek bir karakter
cache[0-9].dat     # köşeli parantez karakter aralığı
!important.log      # ! negasyon: bu dosyayı yine de takip et

Önemli ayrımlar:

• * bölü işareti (/) hariç her şeyle eşleşir; ** ise dizin sınırlarını aşar. Örneğin logs/**/*.log, logs altındaki her derinlikteki .log dosyalarını yakalar.
• Baştaki / kalıbı repo köküne sabitler: /build sadece kökteki build klasörünü dışlar, alt dizinlerdeki build'leri değil.
• Sondaki / yalnızca dizinleri hedefler: build/ aynı adlı bir dosyayı dışlamaz.
• ! ile bir önceki kuralla dışlanan dosyayı geri açabilirsin — ama dosyanın üst klasörü komple ignore edildiyse negasyon işe yaramaz; Git o klasörün içine hiç bakmaz.

Tipik bir .gitignore örneği

Bir Laravel + Node tabanlı projede kök .gitignore aşağı yukarı şöyle görünür:

# Bağımlılıklar
/node_modules
/vendor

# Ortam ve gizli bilgiler
.env
.env.*
!.env.example

# Derleme çıktıları
/public/build
/dist

# Loglar ve geçici dosyalar
*.log
/storage/*.key

# Editör ve işletim sistemi
.DS_Store
.idea/
.vscode/
Thumbs.db

Dikkat: .env.* tüm ortam dosyalarını dışlarken !.env.example satırı örnek şablonu kasıtla takipte tutar — yeni geliştiriciler ona bakarak kendi .env'ini doldurur.

Zaten takip edilen dosyayı dışlamak

Diyelim node_modules/'ı en başta ignore etmeyi unuttun ve commit'ledin. Artık .gitignore'a eklemek yetmez; dosyaları Git'in takibinden çıkarman gerekir. Çözüm, dosyayı diskten silmeden indeksten kaldırmak:

git rm -r --cached node_modules
git commit -m "chore: node_modules'ı takipten çıkar"

--cached bayrağı kritik: dosya çalışma dizininde kalır, sadece Git'in indeksinden çıkar. Bu commit'ten sonra .gitignore kuralı devreye girer ve dosya bir daha eklenmez. Tek bir dosya için git rm --cached dosya yeterlidir.

Global gitignore: kişisel artıkları her yerde sustur

.DS_Store, .idea/ ya da *.swp gibi dosyalar senin işletim sistemine veya editörüne özeldir; bunları her projenin .gitignore'una eklemek ekip arkadaşlarına haksızlıktır. Doğrusu, bir global gitignore tanımlamak:

git config --global core.excludesFile ~/.gitignore_global

Ardından ~/.gitignore_global dosyasına kişisel kalıplarını yazarsın. Bu kurallar sadece senin makinende, tüm depolarında geçerli olur; proje dosyasını kirletmez.

Hazır şablonlar ve hata ayıklama

Her dili sıfırdan yazmana gerek yok. GitHub'ın resmi github/gitignore deposu yüzlerce dil ve araç için hazır şablon barındırır; gitignore.io ise seçtiğin teknolojilere göre birleşik bir dosya üretir. Bunları başlangıç noktası al, sonra projene göre kırp.

Bir dosyanın neden yok sayıldığını anlamak istersen, tahmin etme — Git'e sor:

git check-ignore -v dist/app.js

Bu komut, dosyayı hangi .gitignore'un hangi satırının dışladığını gösterir. Ignore edilmiş bir dosyayı yine de eklemen gerekiyorsa git add -f dosya ile zorlayabilirsin.

Sık Sorulan Sorular

.gitignore'a eklediğim dosya neden hâlâ commit'leniyor?

Büyük olasılıkla dosya zaten takip ediliyor. .gitignore yalnızca untracked dosyaları etkiler. git rm --cached dosya ile indeksten çıkar, sonra commit et; kural ondan sonra çalışır.

Boş bir klasörü repoya nasıl dahil ederim?

Git boş dizinleri takip etmez. Klasörün içine genelde .gitkeep adlı boş bir dosya konur (Git'in resmi bir özelliği değil, sadece bir gelenek) ve o dosya commit edilerek klasör korunur.

.env dosyasını yanlışlıkla yayınladım, ne yapmalıyım?

Önce dosyayı git rm --cached .env ile takipten çıkar ve .gitignore'a ekle. Ama geçmiş commit'lerde kaldığını unutma: gerçekten gizliyse, içindeki tüm parola ve token'ları derhal değiştir/yenile — geçmişi temizlemek tek başına yeterli güvence değildir.

Repolarını temiz tutmak küçük ama kalıcı bir kazançtır. Git altyapısını, deploy akışını veya bir projenin baştan doğru kurulmasını birlikte ele almak isterseniz benimle iletişime geçin.