.gitignore Nedir?
.gitignore, bir Git deposunda hangi dosya ve dizinlerin asla takip edilmemesi gerektiğini tanımlayan düz metin bir kural dosyasıdır. Proje kök dizinine yerleştirilir ve Git bu dosyadaki desenlerle eşleşen her şeyi hem git status çıktısından hem de git add . gibi komutların kapsamından otomatik olarak dışlar. .gitignore olmadan, bir proje büyüdükçe depo da bağımlılık klasörleri, derleme çıktıları ve kişisel editör ayarlarıyla dolar; bu hem depo boyutunu gereksiz yere şişirir hem de ekip üyeleri arasında anlamsız birleştirme çakışmalarına yol açar.
Üç tür içerik neredeyse her .gitignore dosyasında yer alır. Birincisi, package.json gibi bir bağımlılık listesinden yeniden kurulabilen node_modules/ türü klasörlerdir; bunları commit etmek depoyu gereksiz yere büyütür, oysa npm install ile yeniden oluşturulabilirler. İkincisi derleme çıktısıdır: dist/, build/, target/ gibi dizinler kaynak koddan üretilir ve kaynağın kendisiyle birlikte depoda tutulmasına gerek yoktur. Üçüncüsü işletim sisteminin veya editörün ürettiği gereksiz dosyalardır; macOS'ta .DS_Store, Windows'ta Thumbs.db bunun tipik örnekleridir. Bunlara ek olarak .env gibi API anahtarları ve şifreler içeren dosyaların da mutlaka .gitignore'a eklenmesi gerekir, çünkü bu tür sırlar bir kez uzak bir depoya push edildiğinde, sonradan silinse bile geçmişte kalmaya devam eder.
- Bağımlılık klasörleri:
node_modules/,vendor/— paket yöneticisiyle yeniden kurulabilir. - Derleme çıktısı:
dist/,build/,target/— kaynak koddan yeniden üretilir. - Sır (secret) dosyaları:
.env,.env.local— API anahtarı ve şifre içerebilir. - İşletim sistemi/editör dosyaları:
.DS_Store,Thumbs.db,.vscode/,.idea/. - Log ve önbellek dosyaları:
*.log,.eslintcache,__pycache__/.
Desen Söz Dizimi Nasıl Çalışır?
Git'in .gitignore desen eşleştirmesi az sayıda kuraldan oluşur, ama her birinin farklı bir davranışı vardır. * karakteri joker (wildcard) olarak çalışır ve tek bir dizin seviyesindeki herhangi bir karakter dizisiyle eşleşir; # ile başlayan satırlar ise yorum satırıdır ve Git tarafından desen olarak değerlendirilmez, yalnızca dosyayı okunabilir kılmak için kullanılır.
| Desen | Anlamı |
|---|---|
*.log | Adı .log ile biten her dosyayı, hangi dizinde olursa olsun yok sayar. |
build/ | Sonundaki / işareti sadece build adlı dizini hedefler; build adında bir dosya varsa onu etkilemez. |
!.env.example | Başındaki ! işareti, önceki bir kuralla yok sayılmış bir dosyayı istisna tutup yeniden takip edilebilir hale getirir. |
**/logs | Çift yıldız (**) herhangi bir derinlikteki dizinle eşleşir; logs klasörü proje kökünde de olsa alt klasörlerde de olsa yok sayılır. |
# Bağımlılıklar | Yorum satırıdır, herhangi bir dosyayı etkilemez, yalnızca dosyayı bölümlere ayırır. |
.gitignore satır satır yukarıdan aşağıya işlenir, bu yüzden desenlerin sırası önem taşır. Bilinmesi gereken bir sınırlama da şudur: bir dizinin tamamı bir kuralla yok sayılmışsa, o dizinin içindeki tek tek dosyaları ! ile yeniden dahil edemezsiniz — Git zaten yok sayılan dizinin içine hiç bakmaz. İstisna tanımlamak istiyorsanız, üst dizini değil belirli dosya adlarını hedefleyen desenler yazmanız gerekir.
Kritik Tuzak: .gitignore Zaten Takip Edilen Dosyaları Kaldırmaz
En sık karşılaşılan yanılgı şudur: bir dosya .gitignore'a eklenmeden önce zaten git add ve git commit ile depoya kaydedilmişse, kuralı sonradan eklemek o dosyayı tek başına takipten çıkarmaz. Git, bir dosyayı bir kez izlemeye başladığında .gitignore'daki eşleşen desenleri o dosya için görmezden gelir; kural yalnızca henüz hiç takip edilmemiş (untracked) dosyalar için geçerlidir.
Bunun klasik örneği node_modules/ klasörünün yanlışlıkla ilk commit'e dahil edilmesidir. Daha sonra .gitignore dosyasına node_modules/ eklense bile, git status çalışma dizinini temiz gösterse de dosyalar depoda kalmaya devam eder ve her git push ile birlikte gönderilmeye devam eder. Bu durumu düzeltmek için dosyayı Git'in takip index'inden ayrıca çıkarmak gerekir.
# Bağımlılıklar
node_modules/
vendor/
# Derleme çıktısı
dist/
build/
# Ortam değişkenleri ve sırlar
.env
.env.local
# İşletim sistemi ve editör dosyaları
.DS_Store
Thumbs.db
.vscode/
# İstisna: örnek env dosyası takip edilsin
!.env.example
Yukarıdaki gibi bir .gitignore dosyası eklendikten sonra, eğer node_modules daha önceden commit edilmişse aşağıdaki komutları çalıştırmanız gerekir:
# node_modules Git'in takip index'inden çıkarılır (diskteki dosyalara dokunulmaz)
git rm -r --cached node_modules
# değişikliği kaydedin
git commit -m "node_modules klasorunu takipten cikar"
# uzak depoya gonderin
git push
-r bayrağı işlemi dizin içindeki tüm dosyalara özyinelemeli olarak uygular, --cached bayrağı ise dosyaları yalnızca Git'in takip index'inden çıkarır; diskteki gerçek dosyalara dokunmaz. Böylece node_modules klasörü bilgisayarınızda çalışmaya devam eder, sadece bu commit'ten itibaren depo tarafından izlenmekten çıkar. Dosya geçmiş commit'lerden tamamen silinmez; depo geçmişini baştan temizlemek ayrı bir konudur ve git filter-repo gibi ek araçlar gerektirir.
.env dosyası zaten commit edilmişse aynı git rm --cached adımını uygulamak yeterli değildir: içindeki anahtar ve şifreleri de değiştirmeniz gerekir, çünkü dosya geçmiş commit'lerde okunabilir halde kalmaya devam eder.Sık Yapılan Hatalar
- .gitignore dosyasını projeye en baştan değil,
node_modulesveya derleme çıktısı zaten commit edildikten sonra eklemek; bu durumda yukarıdakigit rm --cachedadımı atlanırsa dosyalar takipte kalmaya devam eder. - Aşırı geniş desenler yazmak: örneğin sadece belirli bir log dosyası yerine dikkatsizce genel bir desen kullanmak, projenin ihtiyaç duyduğu bir dosyayı veya gerekli bir klasörü de yanlışlıkla yok sayabilir.
- Dile veya framework'e özgü şablon kullanmamak: bir Python projesine Node.js şablonu (veya tam tersi) uygulamak hem gereksiz kurallar ekler hem de asıl gerekli olan
__pycache__/ya da.venv/gibi desenlerin unutulmasına yol açar. - .gitignore dosyasının kendisini commit etmeyi unutmak; kural dosyası depoya eklenmezse ekip arkadaşlarınız aynı korumadan yararlanamaz.
- Zaten yok sayılan bir dizinin içindeki tek dosyaları
!ile yeniden dahil etmeye çalışmak; Git'in davranışı gereği bu çalışmaz, çünkü yok sayılan dizinin içine hiç bakılmaz.
Doğru Şablonu Elle Yazmak Yerine Oluşturun
Her proje için doğru desen kombinasyonunu ezbere hatırlamak yerine, kullandığınız dil, framework ve işletim sistemine göre standart desenleri otomatik olarak birleştiren bir araç kullanmak hem zaman kazandırır hem de eksik veya hatalı desen riskini azaltır. Gerçek bir proje genellikle birden fazla şablonu üst üste gerektirir; örneğin bir Node.js projesi geliştiren bir macOS kullanıcısı hem Node hem macOS hem de kullandığı editöre ait desenlere aynı anda ihtiyaç duyar.
Node.js, Python, Java, Go, PHP, macOS, Windows, VS Code, JetBrains ve ortam değişkeni desenlerini seçin; tarayıcınızda anında birleştirilmiş .gitignore dosyanızı oluşturun, hiçbir veri sunucuya gönderilmez.
git rm --cached adımına ihtiyaç duymazsınız.