⚠️ Gerçek İş Riskleri ve Takım Güvenlik Kuralları
Gerçek İş Riskleri ve Takım Güvenlik: `git push --force`, `git reset --hard` ve `git clean -fd` gibi komutlar, şantiyedeki bir ekskavatör gibidir: doğru elde saatler kazandırır,
`git push --force`, `git reset --hard` ve `git clean -fd` gibi komutlar, şantiyedeki bir ekskavatör gibidir: doğru elde saatler kazandırır, ama operatör çalıştırmadan önce etrafa bakmazsa altında ne olduğunu ancak kırdıktan sonra öğrenir — ve kırdığı şey çoğu zaman kendi işi değil, başkasının işidir. Peki Git her şeyi kaydediyorsa, bu komutlar neden gerçekten tehlikeli olsun — nasılsa geri alınmaz mı? Kısmen: `reflog` yerel geçmişi bir süre tutar, ama HİÇ commit edilmemiş değişiklikler (`reset --hard` sonrası) ve başkasının makinesindeki tarih (`push --force` sonrası) bu ağın dışındadır — yani Git seni kendi hatandan korur, ekibin geçmişini ezmenden korumaz. Java tarafında en yakın his, paylaşılan bir kütüphanenin yayınlanmış bir sürümünü aynı numarayla yeniden yayınlamaktır: derleyici itiraz etmez, ama o sürümü çeken herkesin elindeki şey sessizce değişir. QA açısından gerçek senaryo şudur: force push’lanan bir branch’te, dün yeşil olan bir testin bugün var olmayan bir commit’e ait olduğu ortaya çıkar — regresyonun ne zaman girdiğini kimse kanıtlayamaz. Kuralı basit tut: paylaşılan branch’te force kullanma, kullanacaksan `--force-with-lease` seç, ekibi önceden haberdar et ve önce bir yedek branch aç.
Try It Yourself: Tehlikeli komut öncesi güvenli kurtarma
`reset --hard` yazmadan önce neyi kaybedeceğini gör ve güvenli yedek al.
Önce çalışma alanı durumunu gör
Kaybedilecek diff’i oku
Yedek branch oluştur
Yedek commit ile çalışmayı sabitle
Geri alma stratejileri: revert vs reset
Revert vs Reset: iki geri alma stratejisi
Revert güvenli yeni commit oluştururken reset history siler. Farkı gör.
Try It Yourself: Güvenli geri alma akışı
Hatalı commit'i güvenli şekilde geri al: önce history'ye bak, revert ile geri al, sonra doğrula.
Önce son commitleri gör
Son commit'i güvenli şekilde geri al