.gitignore Dosyası Nasıl Oluşturulur ve İçine Hangi Kurallar Yazılır?

.gitignore dosyası, Git’in henüz izlemediği hangi dosya ve klasörleri yok sayacağını belirlemek için kullanılır. Oluşturmak için depo kök dizininde bu adla bir düz metin dosyası açıp her satıra bir desen yazabilirsin. Örneğin sanal ortam klasörlerini, günlük dosyalarını ve yerel yapılandırma dosyalarını kurallara ekleyebilirsin.

.gitignore dosyası nasıl oluşturulur ve commit edilir?

Depo kökündeki .gitignore, kural içeren her satırında bir yok sayma deseni bulunan düz metin dosyasıdır. Boş satırlar ve # ile başlayan yorum satırları kural olarak işlenmez.

Depo, projenin dosyalarını ve Git ile kaydedilen değişiklik geçmişini içeren çalışma alanıdır. İzlenen dosya ise Git’in değişikliklerini takip ettiği, daha önce depoya eklenmiş dosyadır.

Bir metin düzenleyicisinde yeni dosya aç ve projenin kök dizinine, yani deponun en üst klasörüne .gitignore adıyla kaydet. Başındaki nokta adın bir parçasıdır; dosyayı .gitignore.txt olarak kaydedersen Git onu amaçlanan .gitignore dosyası olarak kullanmaz.

Kuralları yazıp dosyayı kaydettikten sonra terminalde depo kök dizinindeyken şu komutları çalıştır:

git add .gitignore
git commit -m "Yok sayma kurallarını ekle"

İlk komut dosyanın o anki içeriğini bir sonraki kayıt için hazırlama alanına ekler. İkinci komut, hazırlama alanındaki değişiklikleri bir commit olarak kaydeder. Başka dosyalar da önceden hazırlama alanına eklenmişse onlar da bu commit’e girer; işlemden önce git status ile alanı kontrol edebilirsin.

Desenlerin yazımı ve farklı dizinlerdeki kuralların nasıl değerlendirildiği için Git’in gitignore belgelerine bakabilirsin.

Python projesi için hangi kurallar yazılabilir?

Bir Python projesinde yerel sanal ortamı, önbellek klasörlerini ve günlük dosyalarını yok saymak için aşağıdaki kuralları kökteki .gitignore dosyasına yazabilirsin:

pycache/
__pycache__/
.venv/
.env
*.log

• pycache/, adı tam olarak pycache olan klasörleri ve içindekileri kapsar.
• __pycache__/, Python’ın derlenmiş modül önbelleği için kullandığı __pycache__ klasörlerini kapsar. Bu ad pycache ile aynı olmadığı için ayrıca yazılmıştır.
• .venv/, genellikle yerel Python sanal ortamı için kullanılan .venv adlı klasörleri kapsar.
• .env, adı tam olarak .env olan dosya veya klasörleri kapsar. Örneğin .env.example bu desenle eşleşmez.
• *.log, adı .log ile biten dosya veya klasörleri kapsar. Buradaki * bir joker karakterdir ve adın ilgili bölümünde sıfır ya da daha fazla karakterle eşleşebilir.

Bu desenlerin başında bir dizin yolu bulunmadığından eşleşmeler kökte ve alt klasörlerde aranır. Sondaki / işareti ise ilgili desenin klasörlerle eşleşmesini sağlar.

Örneğin kuralları commit edilmiş bir depoda uygulama.py dosyasının zaten izlendiğini ve sonradan değiştirildiğini düşün. Aynı depoda daha önce izlenmemiş .env, hata.log ve __pycache__/ da bulunsun. Şu komutu çalıştırdığında:

git status --short

Çıktı şu şekilde olabilir:

 M uygulama.py

M, izlenen kaynak dosyasında değişiklik bulunduğunu gösterir. Yok sayılan, önceden izlenmemiş dosyalar normal durumda bu listede görünmez; gerçek çıktı depodaki diğer değişikliklere ve Git ayarlarına bağlıdır. Yok sayılanları da görmek için git status --ignored komutunu kullanabilirsin.

.gitignore, daha önce izlenmeye başlanmış bir dosyanın takibini kendiliğinden durdurmaz. Böyle bir dosyayı yerel kopyasını koruyarak takipten çıkarmak için git rm --cached dosya_adi kullanabilir, ardından değişikliği commit edebilirsin. Bu işlem dosyanın önceki commit’lerdeki kaydını kaldırmaz.

Dosya, klasör ve joker karakter kuralları nasıl yazılır?

.gitignore içindeki her desen, Git’in hangi izlenmeyen dosya veya klasörleri yok sayacağını belirler. Git tarafından zaten izlenen, yani depoda takibi yapılan dosyalar bu kurallardan etkilenmez.

Joker karakter, bir dosya yolundaki değişken bölümleri tek tek yazmadan eşleştirmeye yarayan işarettir. Aşağıdaki kuralların deponun kök dizinindeki .gitignore dosyasında bulunduğunu düşün:

rapor.txt
*.log
/gecici/
veri/*.csv
arsiv/**/rapor.txt

• rapor.txt, kök dizindeki ve alt klasörlerdeki aynı adlı dosya veya klasörlerle eşleşir.
• *.log, adı .log ile biten dosya veya klasörleri farklı dizin seviyelerinde eşleştirebilir. Tek yıldız, dosya yolundaki / karakterini eşleştirmez.
• /gecici/, yalnızca kökteki gecici klasörünü ve içeriğini hedefler. Baştaki eğik çizgi konumu, sondaki eğik çizgi ise eşleşmenin klasörle sınırlı olduğunu belirtir.
• veri/*.csv, veri/liste.csv ile eşleşir; yıldız eğik çizgiyi kapsamadığından veri/eski/liste.csv ile doğrudan eşleşmez.
• arsiv/**/rapor.txt, arsiv/rapor.txt, arsiv/2025/rapor.txt ve daha derindeki aynı adlı dosyalarla eşleşir. Buradaki **/, sıfır veya daha fazla klasör seviyesini temsil eder.

Eğik çizginin yeri sonucu değiştirir. Örneğin gecici/ farklı seviyelerdeki gecici klasörleriyle eşleşirken /gecici yalnızca kökteki aynı adlı dosya veya klasörle eşleşir. Yalnızca kökteki klasörü hedeflemek için iki tarafta da eğik çizgi kullanabilirsin: /gecici/.

Çift yıldızın özel anlamı bulunduğu konuma bağlıdır; desenlerin ayrıntılarını Git’in gitignore belgelerinde inceleyebilirsin.

İstisnalar ve alt klasör kuralları nasıl çalışır?

Bir desenin başına ! koyarak daha önce yok sayılmış uygun bir dosya için istisna tanımlayabilirsin. Aynı .gitignore dosyasında bir yolla eşleşen kurallar arasında son eşleşen kural geçerlidir:

*.log
!ornek.log

Bu kurallarla hata.log yok sayılırken ornek.log yeniden dikkate alınır. Ancak dosyanın bulunduğu üst klasörün kendisi yok sayılmışsa içindeki dosya doğrudan istisna yapılarak geri alınamaz.

Örneğin kayitlar/ kuralı klasörün tamamını dışladığında, ardından yazılan !kayitlar/ornek.log tek başına işe yaramaz. Klasörün kendisini dışlamadan, doğrudan içeriğini hedefleyerek istisna oluşturabilirsin:

/kayitlar/*
!/kayitlar/ornek.log

Bu örnekte kayitlar/hata.log yok sayılır, kayitlar/ornek.log ise dikkate alınır. Daha derindeki bir dosyaya istisna tanımlarken aradaki klasörlerin de dışlanmamış olması gerekir.

Alt klasörlere ayrı .gitignore dosyaları koyabilirsin. Bu dosyalardaki kurallar kendi konumlarına göre uygulanır ve aynı dosya yoluyla ilgili bir çakışmada daha alt klasördeki .gitignore önceliklidir.

Paylaşılmasını istemediğin, yalnızca kendi depo kopyana özgü yok sayma kurallarını .git/info/exclude dosyasına yazabilirsin. Bu dosya, projeyle birlikte paylaşılan .gitignore dosyasını değiştirmeden yerel kurallar tanımlamana yardımcı olur.

Bir dosyanın neden yok sayıldığı nasıl anlaşılır?

git check-ignore -v komutu, bir dosya yoluyla eşleşen yok sayma kuralının nerede bulunduğunu gösterir. Örneğin deponun, yani projenin Git tarafından yönetilen dizininin kökünde şu komutu çalıştırabilirsin:

git check-ignore -v .env

Kök dizindeki .gitignore dosyasının üçüncü satırında .env kuralı varsa ve dosya daha önce izlenmeye alınmadıysa örnek çıktı şöyle olabilir:

.gitignore:3:.env	.env

Çıktıdaki ilk .gitignore kuralın bulunduğu dosyayı, 3 satır numarasını, sonraki .env ise eşleşen deseni gösterir. Son bölümde sorgulanan dosyanın yolu yer alır. Komut çıktı üretmiyorsa yolun bir kuralla eşleşmemesi veya dosyanın zaten izleniyor olması gibi olasılıkları kontrol edebilirsin.

Git'in değişikliklerini takip ettiği, yani önceden izlenen bir dosya, .gitignore dosyasına kural eklenince kendiliğinden izlenmekten çıkmaz. Böyle bir dosyayı kendi bilgisayarında tutarak Git'in bir sonraki commit için hazırladığı içerikten, yani indeksten çıkarmak üzere git rm --cached .env komutunu kullanabilirsin; bu değişikliği içeren sonraki commit dosyanın kaldırılmasını kaydeder. Dosyaya uygun yok sayma kuralını da ekleyerek daha sonra yanlışlıkla yeniden eklenmesini önleyebilirsin.

Gizli bilgiler depodan nasıl uzak tutulur?

API anahtarları gibi gizli bilgileri depodan uzak tutmak için bunları içeren dosyaları commit etmeden önce yok sayma kurallarını kontrol et. Örneğin kök dizindeki .env dosyası için .gitignore içine şu kuralı yazabilirsin:

/.env

Ardından git check-ignore -v .env ile kuralın eşleştiğini, git status ile de commit için hazırlanan değişiklikleri kontrol et. Yok sayma kuralları mevcut izlenmeyen dosyalar için çalıştığından, kuralı eklemekle yetinmeden hazırlanan dosyaları gözden geçirmek önemlidir.

.gitignore dosyasına sonradan kural eklemek, daha önce commit edilmiş bir sırrı Git geçmişinden silmez. Bir anahtar yanlışlıkla paylaşıldıysa ilgili sağlayıcı üzerinden onu iptal et veya değiştir; gerekiyorsa depo geçmişinin ve diğer kopyaların temizlenmesini de ekip arkadaşlarınla birlikte değerlendir.

Yok sayma kurallarını ve commit için hazırlanan değişiklikleri düzenli olarak kontrol etmek, hangi dosyaların depoya gireceğini takip etmene yardımcı olur.