Git geçmişine giren bir sır neden yalnız dosyadan silinerek korunamaz?

Bir sır Git deposuna commit olarak girdiyse, dosyanın güncel hâlinden silinmesi onu korumaz; sır eski commit'lerde, dallarda, etiketlerde, başka klonlarda ve yedeklerde kalabilir. Bu nedenle doğru yaklaşım sırrı sağlayıcıda hemen geçersiz kılmak, ardından erişimi ve gerekiyorsa geçmiş temizliğini planlamaktır. Geçmiş yeniden yazılsa bile daha önce çekilmiş kopyalar otomatik olarak temizlenmez.

Git geçmişinde sır nasıl kalır?​

Git çoğunlukla dosyanın yalnız son hâlini değil, commit'lerin içeriklerini ve aralarındaki değişiklikleri de saklar. Örneğin bir geliştirici önce .env dosyasını commit edip sonra bu dosyayı silerse, silme commit'inden önceki commit'e geçildiğinde dosyanın eski hâli görülebilir.

Bir commit'te bulunan gizli anahtar şu yollarla tekrar elde edilebilir:

• Eski commit'i inceleyerek veya eski bir dala geçerek.
• Etiketlenmiş sürümleri ve release arşivlerini indirerek.
• Daha önce oluşturulmuş geliştirici klonlarından veya CI/CD çalışma alanlarından.
• Uzak depo, yedek, önbellek ya da log kayıtlarından.

Bu yüzden "dosyayı sildim" sonucu yalnızca mevcut çalışma ağacını düzeltir; ifşanın kendisini geri almaz.

Somut örnek​

Bir projede config.json dosyasına şu değer commit edilmiş olsun:


Daha sonra değer dosyadan silinse ve değişiklik uzak depoya gönderilse bile eski commit hâlâ bu anahtarı içerir. Anahtarın Git geçmişinden tamamen kaldırılması, anahtarın daha önce görülmüş olabileceği gerçeğini değiştirmez. Anahtarı kullanan servis onu geçersiz kılmadıkça saldırgan eski değeri kullanmayı deneyebilir.

Uygulanacak doğru sıra​

1. Sırrı derhâl iptal edin veya yenileyin. API anahtarı, parola, erişim belirteci ya da sertifika gibi değeri üreten sistemden yeni bir değer alın. Eski değerin artık çalışmadığını doğrulayın. Geçmişi temizlemek, çalışan bir sırrı kendiliğinden geçersiz kılmaz.
2. Sırrın nerelerde kullanıldığını kontrol edin. Uygulama ayarları, CI/CD değişkenleri, dağıtım sistemleri, loglar ve kişisel kopyalar ayrı ayrı değerlendirilmelidir.
3. Geçmişi yeniden yazmanın gerekip gerekmediğini değerlendirin. İptal edilen sır tek başına riskin giderilmesine yetebilir; yasal veya kurumsal gerekçe varsa yetkili referanslar ve eski dosya adlarıyla dar kapsamlı plan hazırlayın. Araç, dal/etiket kapsamı, yedek, açık pull request ve dağıtım etkisi ekipçe gözden geçirilmeden force/mirror push çalıştırmayın.
4. İşlem sonrasında depo geçmişinde dosya ve sır için arama yapın. Temizlenen uzak depoyu yeniden klonlayarak beklenmeyen referansların kalmadığını kontrol edin.
5. Ekip üyelerinin eski klonlardan eski geçmişi tekrar göndermesini önleyin; gerekli çalışma dosyalarını koruyarak yeni ayrı dizinde temiz klonla devam etmeyi koordine edin. Eski klonlarla çalışmaya devam etmek, silinen commit'lerin yeniden uzak depoya gönderilmesine yol açabilir.
6. Dosyayı tekrar eklemeyin. Gizli değerleri ortam değişkenlerinde veya uygun bir sır yönetim sisteminde tutun; depoya yalnızca örnek yapılandırma dosyası koyun.

Bu işlem ortak depoda commit kimliklerini ve dalların geçmişini değiştirir. Başka ekiplerin kullandığı dallar, fork'lar veya otomatik dağıtım süreçleri varsa force push öncesinde koordinasyon gerekir. Büyük ve paylaşılan depolarda yalnızca belirli bir commit'i silmeye çalışmak yerine, etkilenen tüm referansları ve kopyaları planlamak daha güvenlidir.

Hangi işlem hangi sorunu çözer?​

Aşağıdaki ayrım, yalnızca dosyayı silmenin neden yetersiz olduğunu ve hangi adımın gerekli olduğunu gösterir.


Tablodaki işlemler birbirinin alternatifi değildir. Özellikle sır ifşasında önce iptal veya yenileme yapılmalı, geçmiş temizliği bunun ardından uygulanmalıdır.

Sık yapılan hatalar​

Yalnızca son commit'i düzeltmek: Eski commit'ler hâlâ erişilebilir olabilir. Geçmişteki tüm ilgili referanslar incelenmelidir.

Yeni anahtarı aynı geçmişe eklemek: Eski değer iptal edilmeden yeni değer commit edilirse sorun büyür. Yeni sır da daha sonra ifşa edilmiş sayılabilir.

Force push sonrasında işi bitmiş sanmak: Fork, yedek, CI önbelleği ve geliştirici klonları ayrı kopyalardır. Bunların temizlenmesi veya kullanımdan kaldırılması gerekir.

Temizlenen dosyayı tekrar üretmek: .gitignore yalnız izlenmeyen dosyalara uygulanır; zaten takip edilen dosyayı veya eski commit içeriğini gizlemez. İzlemeyi bırakma ve dosyanın yerelde korunması ayrı planlanmalıdır. Bu nedenle hem geçmiş temizlenmeli hem de gizli yapılandırma dosyaları izlenmeyen hâle getirilmelidir.

Sık sorulan sorular​

Revert commit gizli değeri geçmişten kaldırır mı?​

Hayır. Revert yeni bir karşı değişiklik commit’i oluşturur; önceki commit’in içeriğini yok etmez. Sırrı iptal etmek ve gerekliyse koordine geçmiş işlemi ayrı konulardır. Güncel dosyanın temiz olması geçmişteki içeriğin erişilmez olduğunu kanıtlamaz.

Ignore kuralını eklediğim dosya neden hâlâ değişiklikte görünüyor?​

Dosya zaten Git tarafından takip ediliyor olabilir. Ignore kuralı geçmişe veya mevcut takip kaydına otomatik uygulanmaz. Gizli değeri depodan uzak tutarken yerel uygulamanın gereken dosyasını koruyacak dar bir geçiş planlayın; yeni sırrı tekrar commit etmeyin.