Klasör taşıma .gitignore çapasını bozdu ve canlı kimlik bilgilerini neredeyse commit'ledi

Ne oldu

dev.to'da yazan bir geliştirici, rutin bir repository yeniden düzenlemesinin iki .gitignore pattern'inin eşleşmesini sessizce durdurduğu — bunlardan birinin canlı kimlik bilgileri içeren bir dosyayı kapsadığı — bir tehlike atlatma vakasını belgeledi.

Repository, çeşitli script'lerle birlikte birkaç üst düzey dizine yayılmış bir Swift uygulaması içeriyordu. Codebase'e bir Android uygulaması eklendiğinde, yazar Swift tarafını yeni bir apple/ dizinine toplamak için git mv kullandı; böylece apple/ ve android/ yan yana durdu. Dosyaların içeriğinde hiçbir şey değişmedi, her iki platform da derlenmeye devam etti ve tüm kontroller geçti.

Sorun, yazar git'in commit etmeyi önerdiğini incelediğinde ortaya çıktı. O ana kadar yok sayılan iki path untracked olarak görünüyordu: apple/Support/pooled-flight/ ve apple/Support/telemetry.env — ikincisi canlı bir Supabase URL'si ve anahtarı içeriyordu. Gönderiye göre, bakmadan yapılan tek bir git add -A komutu bu kimlik bilgilerini bir remote'a göndermiş olurdu.

Tek bir slash her şeyi belirliyor

Repository'nin .gitignore dosyasında beş pattern vardı: build/, *.xcodeproj, dist/, Support/telemetry.env ve Support/pooled-flight/. Bunlardan üçü klasör taşınmasından sonra çalışmaya devam etti, ikisi etmedi — ve fark tek bir slash'taydı.

Gönderi, gitignore spesifikasyonunu şöyle özetliyor: bir pattern, sonda olmayan bir yerde slash içeriyorsa, .gitignore dosyasını içeren dizine göre yorumlanır. İç slash içermeyen pattern'ler ise her derinlikte isme göre eşleşir.

Dolayısıyla build/, apple/build/ ile eşleşmeye devam etti ve *.xcodeproj, ağacın herhangi bir yerinde eşleşmeye devam etti. Ancak Support/telemetry.env iç slash içeriyordu ve bu nedenle repository köküne çapalanmıştı; yani tam olarak üst düzeydeki Support/telemetry.env anlamına geliyordu. Dosya apple/Support/telemetry.env olduğu anda pattern artık onu tanımlamıyordu ve git bir secrets dosyasını sıradan bir untracked dosya olarak sunmaya başladı.

Yazar, bu davranışın belgelenmiş ve doğru olduğunu — ama tamamen sessiz olduğunu vurguluyor. Git, bir pattern'in eşleşmeyi bıraktığı konusunda asla uyarmaz, çünkü hiçbir şeyle eşleşmeyen bir pattern çoğu zaman normal bir durumdur. Özellikle, dosya da .gitignore da düzenlenmemişti; ağaç, yalnızca ikisinin üzerine bir dizin büyütmüştü.

Varsaymak yerine doğrulamak

Adli incelemeyi iki komut yaptı. git check-ignore -v, bir path'i yok saymakla sorumlu olan kesin pattern'i ve satır numarasını raporlar — ve hiçbir şey yazdırmıyorsa, dosya yok sayılmıyor demektir. Yazar, bu asimetriyi içselleştirmeye değer olarak işaretliyor: tehlikeli cevap, sessiz olandır.

İkinci soru, kimlik bilgilerinin herhangi bir noktada herhangi bir branch'e commit edilip edilmediğiydi. git log --all --oneline -- '*telemetry.env' komutu boş bir sonuç döndürdü ve bunun bir olay değil, tehlike atlatma olduğunu doğruladı. Sonuç boş olmasaydı, yazarın belirttiği işlem sırası sabitti: önce kimlik bilgisini rotate et, sonra geçmişi yeniden yazma derdine düş — bu sırada, asla ters çevirmeden.

Düzeltme ve daha iyi düzeltme

Bariz onarım, pattern'leri apple/Support/telemetry.env ve apple/Support/pooled-flight/ olarak yeniden yönlendirmektir. Bu bugün işe yarar ama herhangi bir şey bir daha taşındığında bozulur; yazar bunu aynı tuzağı yeniden kurmak olarak tanımlıyor.

Daha iyi onarım, çapalamayı tamamen kaldırıp telemetry.env ve pooled-flight/ kullanmaktır. İç slash olmadan bunlar, ağacın bir sonraki sefer nereye giderse gitsin, her derinlikte isme göre eşleşir. Takas, biraz daha geniş eşleşmedir — herhangi bir yerde telemetry.env adlı her dosya artık yok sayılır — ki yazar, bir secret için bunun imprecise olunacak doğru yön olduğunu savunuyor.

Neden önemli

İç slash içeren yok sayma pattern'leri dizin yapınıza bağlıdır. Build çıktısı için bu bağlılık çoğunlukla zararsızdır: dist/ yok sayılmaz olur ise, bir şeyin aşağıda yanlış çalışmasıyla fark edersiniz. Secrets için ise sessizdir — dosya, tam da ilgisiz bir refactor hakkında düşünüp meşgul olduğunuz anda commit'lenebilir hale gelir.

Gönderinin pratik çıkarımları geniş ölçüde geçerlidir. Hassas her şey için yalnızca isimden oluşan pattern'leri tercih edin: config/telemetry.env yerine telemetry.env, keys/*.p12 yerine *.p12 — biraz hassasiyet pahasına gelecekteki yeniden yapılandırmalara bağışıklık kazanın. Her yapısal değişiklikten sonra, git status çıktısını özellikle出现 hiçbir yerden gelmeyen untracked dosyalar için tarayın — gerçekten taşıdığınız dosyalar rename olarak görünür ve güvenlidir; bir taşımadan sonra yeni untracked olan her şey, daha önce çapalı bir pattern tarafından kapsanıyordu. Ve secrets'larınız için git check-ignore -v çalıştırın, çünkü düz bir cevap veren tek komut odur ve tehlikeli sonuç, hiçbir şey yazdırmayan sonuçtur.