Lovable uygulaması son düzenlemeden sonra bozulduğunda: teşhis sırası

Lovable'da gönderdiğin bir prompt bazen hiç dokunmadığın bir ekranı bozar. Bunun sebebi neredeyse hiçbir zaman veri kaybı değildir, paylaşılan bir component ya da yardımcı fonksiyonun sözleşmesinin değişmesidir. Doğru sırayla teşhis edersen version history seni dakikalar içinde geri getirir. Yanlış sırayla gidersen üstüne attığın her yeni prompt aynı kırığın üstüne bir kat daha ekler.

Önce doğrula: bu gerçekten son prompt mu, yoksa başka bir şey mi

"Bozuldu" dediğin an üç farklı şeyden biri olabilir, ve ikisi son gönderdiğin promptla hiç ilgili değil. Önce Lovable'ın durum sayfasını (status.lovable.dev) kontrol et, aktif bir kesinti varsa bundan sonraki teşhis boşa gider. Sonra tarayıcı önbelleğini sil ve sayfayı zorla yenile, "bozuldu" raporlarının bir kısmı önbellekte kalmış eski bir build'den ibaret. Bu ikisi de değilse geriye tek açıklama kalıyor: son promptun bir şeyi değiştirdi ve o değişiklik beklemediğin bir yere sıçradı.

Lovable'ın zaten tuttuğu geçmişte neye bakacaksın

Editörün üst çubuğundaki History sekmesini aç, ya da sohbet kutusunun yanındaki + menüsünden Project, sonra History yolunu izle. Panel iki sekmeden oluşuyor: History bütün sürümleri listeliyor, Bookmarks ise kararlı olarak işaretlediklerini. Listedeki herhangi bir sürüme tıkladığında hiçbir şey değişmeden o anın önizlemesi açılıyor, sadece bakıyorsun.

Aradığın tek şey şu: bu ekran son hangi sürümde çalışıyordu, ve o sürümle şimdi arasında kaç sürüm, fark ettiğin ekranla ilgisi olmayan dosyalara dokunmuş. Cevap "birkaçı" ise kırılma büyük ihtimalle paylaşılan bir dosyada duruyor.

Diff'i tek dosyaya indirgediğinde kırılan satır kendini gösterir

Proje GitHub'a bağlıysa her düzenleme senkronlanan dalda bir commit olarak düşer. Bozulan ekranın arkasındaki dosyayı bul, git log --oneline -- <dosya> ile o dosyaya son dokunan commit'i çıkar, sonra diff'i tüm commit'i okumak yerine sadece o dosyaya indir. Aşağıdaki örnek gerçekte nasıl olduğunu taklit ediyor: bir prompt "toplamı gösteren bir ödeme butonu ekle" diyor, bunun için paylaşılan bir fiyat formatlama fonksiyonuna dokunuyor, ve ödeme butonu hiç istemeyen bir ekran (sepet toplamı) aynı fonksiyonu çağırdığı için bozuluyor. Bunlar örnek bir repoya karşı gerçekten çalıştırılmış komutlar, temsili değil.

$ git log --oneline
b966a52 Add checkout button with price
e2a2260 Add cart total display

$ git diff HEAD~1 HEAD -- src/lib/format.ts
diff --git a/src/lib/format.ts b/src/lib/format.ts
index 7bac477..835dfdf 100644
--- a/src/lib/format.ts
+++ b/src/lib/format.ts
@@ -1,3 +1,3 @@
-export function formatPrice(cents: number) {
-  return `${(cents / 100).toFixed(2)} TL`;
+export function formatPrice(amount: number) {
+  return `${amount.toFixed(2)} TL`;
 }

Bu diff kendi başına tehlikeli görünmüyor. Ödeme butonu artık tam tutar bekleyecek şekilde kendi hesabını yapıyor, ama sepet toplamı aynı fonksiyonu eski mantıkla çağırmaya devam ediyor, bu yüzden tutarı yüz katına çıkararak gösteriyor. Commit mesajı sepetten hiç bahsetmiyor, ve tam olarak bu yüzden tüm commit'i okumak, değişen tek dosyaya diff'i indirmekten daha yavaş.

Yeni özelliği kaybetmeyen düzeltme, tüm commit'i geri almaktan daha dar: sadece o dosyanın eski sözleşmesini geri çek, gerisine dokunma.

$ git checkout HEAD~1 -- src/lib/format.ts
$ git commit -m "Revert formatPrice contract, keep checkout button"
$ cat src/lib/format.ts
export function formatPrice(cents: number) {
  return `${(cents / 100).toFixed(2)} TL`;
}

Bu, Lovable'ın tüm commit'i revert etmesinden farklı bir hamle, çünkü o hamle az önce istediğin ödeme butonunu da götürür. Bir sonraki bölüm üç hamleden hangisini ne zaman seçeceğini anlatıyor.

Revert mi, revert and resend mi, yoksa dar bir fix commit mi

Hamle	Ne yapar	Veritabanına dokunur mu?
Revert	Projenin tüm kodunu önceki bir sürüme döndürür, edge function'ları buna göre yeniden dağıtır. Yeni özelliği de birlikte götürür.	Hayır, veri olduğu gibi kalır
Revert and resend	Geçmişteki bir mesajı düzenler ve aradaki geçmişi kaybetmeden oradan yeni talimatla devam eder.	Hayır
Dar fix commit	Sadece paylaşılan dosyanın eski sözleşmesini geri getirir, sonrasındaki her şeyi korur	Hayır

Son promptları çözmek yerine tamamen silmeyi tercih ediyorsan düz revert'e uzan. Son promptun fikri doğruydu ama uygulaması sapıttıysa, aynı fikri daha iyi bir talimatla yeniden denemek için revert and resend'e uzan. Yukarıdaki örnekteki gibi regresyon ve korumak istediğin özellik aynı commit'te duruyorsa ve sorun olan sadece biriyse, dar bir fix commit'e uzan. Planlamadan önce bilmen gereken bir sınır var: çok eski sürümler önizlenebilir ama Lovable o kadar geriye revert edemeyeceğini açıkça söylüyor, gerçek bir regresyonu haftalarca o pencerenin dışına düşmeden ele al.

GitHub senkronu açıksa commit'i geri almakla satırı geri almak farklı şeyler

Lovable'da git senkronu çift yönlü ve otomatik: Lovable'da yaptığın değişiklikler senkronlanan dala commit olarak düşüyor, ve dışarıdan o dala yapılan push'lar projeye geri yansıyor. Aynı anda tek bir dalı takip ediyor, genelde main, Project settings'ten seçtiğin. Lovable o dalın kendi kopyasını tutuyor, ve tam bu yüzden dışarıdan force-push, rebase ya da squash yapmak gerçek çakışmalar doğuruyor. Bir şeyi geri almanın belgelenen yolu, yukarıda çalıştırdığımız hamleyle aynı: geçmişi yeniden yazmak yerine, onu geri alan bir commit eklemek. Normal bir revert commit'ini normal şekilde push etmek desteklenen yol, çünkü senkron tam olarak bunu geri taşımak için tasarlanmış. Sorun yaratan şey dalın geçmişini yeniden yazmaya çalışmak, geleceğine bir şey eklemek değil.

İçeride çözülür mü, kodu dışarı alma sinyali mi

Yukarıdaki adımların bulduğu şeylerin çoğu içeride çözülür: paylaşılan bir fonksiyonun sözleşmesi değişmiş, dar bir revert ya da resend bunu düzeltir ve inşaya devam edersin. İş değişir eğer diff satır seviyesi güvenlik politikalarına, auth'a ya da bir secret'a dokunuyorsa, bu tam olarak Lovable ve Bolt ile yapılan uygulamaların neyi açıkta bıraktığı yazımızda anlattığımız kırılma biçimi, ve kazara bulduğun bir güvenlik açığını bir promptla kapatmaya çalışmazsın. Kırılma Lovable'ın geri gidebildiği sürümden daha eskiyse, ya da yeterince dosyaya yayılmışsa dar bir fix artık dar kalmıyorsa da iş değişir. O noktada soru "ne değişti" değil, "bir sonraki ödeme yapan kullanıcı dokunmadan önce bu kod tabanı ikinci bir göze mi ihtiyaç duyuyor" sorusu, ve yaptırmak mı kendin mi karar hesaplayıcı aracımız bunu tahmin etmekten daha hızlı gösteriyor.

Bu teşhis sırası kodun hâlâ var olduğunu ve sorunun bir regresyon olduğunu varsayıyor, kaybolmuş bir proje değil. Bir sonraki adımın bir kırığı daha teşhis etmek değil, kodu kendi kontrolündeki bir altyapıya taşımak olduğuna çoktan karar verdiysen, Lovable kodunu GitHub'a çıkarmak yazımız neyin geldiğini neyin gelmediğini anlatıyor. Kod tabanının kendisi production trafiğine güvenilmeden önce gerçek bir incelemeye ihtiyaç duyuyorsa, yapay zeka projesi tamamlama işimiz tam buradan başlıyor, bir şeyi değiştirmeden önce ne olduğunu okuyarak.

Bir daha teşhise ihtiyaç duymamak için kur: bookmark ve prompt disiplini

Paylaşılan bir dosyaya, birden fazla özelliğin bağlı olduğu bir dosyaya dokunacak bir prompt göndermeden önce o sürümü bookmark'la. Bu, "bir saat önceki bir sürüme dön"ü "iyi olduğunu bildiğim tam noktaya dön"e çevirir, ki iki dakikalık bir düzeltmeyle uzun bir düzeltme arasındaki fark tam olarak bu. Prompt tarafında Lovable'ın kendi tavsiyesi şu: "Try to fix"e bir ya da iki kereden fazla yaslanma (ücretsizde ayda 10 kullanımla sınırlı, her 24 saatte sıfırlanıyor), bundan sonra Plan mode'a geç ve daha fazla kod yazmadan önce kök sebebi adlandırmasını iste. Aynı disiplin kırılmaya sebep olan prompt için de geçerli: hangi dosyaya ya da component'e dokunulmasını istediğini açıkça yazmak, bir düzenlemenin istemediğin bir yere sıçrama sıklığını düşürüyor.

Sık sorulan sorular

Lovable'da revert veritabanımı da geri alır mı?
Hayır. Revert sadece kodu geri getiriyor ve edge function'ları buna göre yeniden dağıtıyor. O andan sonra yazılan veri olduğu gibi kalıyor.

Gerçekte kaç sürüm öncesine revert edebilirim?
Lovable her sürümü tutuyor, ama çok eski olanlar sadece önizlenebiliyor, geri yüklenemiyor, ve editör bunu doğrudan söylüyor. Gerçek bir regresyonsa, o pencerenin dışına eskimeden harekete geç.

GitHub'a bağlı değilim, yine de ne değiştiğini görebilir miyim?
Evet. History panelinin snapshot önizlemesi herhangi bir eski sürümü açıp gözle karşılaştırmana yetiyor, git gerekmiyor.

Önce hep "Try to fix" mi denemeliyim?
Bir, en fazla iki kere. Sonrasında Lovable'ın kendi tavsiyesi kör kör denemeyi bırakıp Plan mode'a geçmek, böylece daha fazla kod yazmadan önce AI sebebi adlandırıyor.

Geri almam gereken paylaşılan dosyada korumak istediğim değişiklikler de varsa?
Tam olarak dar fix commit'in işi bu: eski dosyayı önceki commit'e karşı düz bir checkout ile geri çek, sonra tüm commit'i değil sadece o dosyayı commit'le.