AI ile Oluşturulmuş Uygulamada Git Nasıl Kullanılır

AI ile yapılmış bir uygulamada Git kullanmak için projeyi bir Git deposuna bağlayın, çalışan her değişiklikten sonra commit atın, neyin değiştiğini anlatan tek satırlık bir mesaj yazın ve gizli bilgileri bir .gitignore dosyasıyla dışarıda tutun. Riskli işler için bir dal kullanın, başka biri kodu değiştirdiyse tekrar istem yazmadan önce çekin ve AI bir şeyi bozduğunda, sorunun üzerine yeni istemler yazmak yerine son çalışan commit'e geri dönün.

Git bir sürüm kontrol sistemidir: kodunuzun kaydedilmiş her sürümünün geçmişini tutar. GitHub ise Git depolarını çevrim içi saklayan bir web sitesidir. Bu kavramlar yeniyse GitHub nedir yazısıyla başlayın. Bu rehber, AI kodun büyük kısmını yazarken Git'i faydalı kılan alışkanlıklarla ilgilidir.

AI ile Git neden daha önemli

Bir AI tek bir turda yirmi dosyayı değiştirebilir. Bu hızlıdır, ama aynı zamanda tek bir istem dün test ettiğiniz bir şeyi sessizce bozabilir. Git size şunları sağlar:

• Geri dönüş yolu. Commit edilmiş herhangi bir sürüm geri yüklenebilir.
• Neyin değiştiğinin kaydı. Bir istemin hangi dosyalara ve hangi satırlara dokunduğunu tam olarak görebilirsiniz.
• Oluşturucunun dışında bir kopya. Kodunuz kendi kontrolünüzdeki bir yerde durur.
• Standart bir devir teslim. Her geliştirici, hizmet ya da araç bir Git deposuyla çalışabilir.

Adım 1: Bir depo bağlayın

GitHub ya da benzeri bir serviste bir depo oluşturun (genellikle özel) ve projenizi buna bağlayın. Git'i destekleyen çoğu AI uygulama oluşturucu bunu, "GitHub'a bağlan" düğmesi bulunan bir ayarlar sayfasından yapar. Sizinki yapmıyorsa kodu dışa aktarıp kendiniz gönderebilir ya da bir kez kurulum yapması için bir geliştiriciden yardım isteyebilirsiniz.

İlk göndermeden önce, depoda olmaması gereken şeylerin yok sayıldığından emin olun:

.gitignore dosyasını kontrol et. .env dosyalarını, node_modules klasörünü, derleme çıktısı klasörlerini ve gizli bilgi içeren her dosyayı dışarıda bıraktığından emin ol. Eklediğin şeyleri bana söyle.

Adım 2: Çalışan her değişiklikten sonra commit atın

Commit, mesajı olan kaydedilmiş bir anlık görüntüdür. Önemli olan alışkanlık şudur: bir şey çalıştığında, bir sonraki isteği yazmadan önce commit atın.

1. Tek bir değişiklik isteyin.
2. Önizlemede kontrol edin.
3. Çalışıyorsa bir mesajla commit atın (ya da senkronize edin).
4. Sonra devam edin.

Küçük commit'ler, bir şey bozulduğunda hangi değişikliğin bunu yaptığını bilmeniz ve geri almanın diğer işlerinizi silmemesi anlamına gelir.

Adım 3: Sonradan okuyabileceğiniz mesajlar yazın

İyi bir mesaj, neyin ve neden değiştiğini tek satırda anlatır:

• İyi: Sipariş sayfasına CSV dışa aktarma ekle
• İyi: Rezervasyon formunun akşam 6'dan sonraki saatleri reddetmesini düzelt
• Faydasız: güncelleme, değişiklikler, bir şeyler düzeltildi

Bu mesajları AI'dan yazmasını da isteyebilirsiniz:

Son commit'ten bu yana yapılan değişiklikleri bir fiille başlayan, 70 karakteri geçmeyen tek satırla özetle.

Adım 4: Riskli işler için dal kullanın

Dal, ayrı bir çalışma hattıdır. Bir şeyi dal üzerinde deneyebilir, işe yaramazsa ana sürüme dokunmadan bırakabilirsiniz.

Şu durumlarda bir dal kullanın:

• Değişiklik büyükse (yeniden tasarım, yeni bir ödeme akışı, bir veritabanı değişikliği).
• Aynı uygulama üzerinde başka biri çalışıyorsa.
• Değişikliğin yayına girmeden önce birinin incelemesini istiyorsanız.

İş bittiğinde ve test edildiğinde, ana dala birleştirilir. GitHub'da bu genellikle, değişiklikleri inceleme için gösteren bir sayfa olan pull request üzerinden olur. Oluşturucunuz yalnızca tek bir dalı senkronize ediyorsa, dalları GitHub tarafında bir geliştirici yönetebilir.

Adım 5: Güvenle geri alın

Bir istem uygulamayı bozduğunda, üzerine beş istem daha yazma isteğine direnin. Son çalışan sürüme dönün ve daha net bir istem deneyin.

• Oluşturucuda: varsa kontrol noktası ya da geri yükleme özelliğini kullanın.
• Git'te: git revert, eski bir commit'i geri alan yeni bir commit oluşturur ve geçmişi bozulmadan tutar. Başkalarının çekmiş olabileceği kod için güvenli seçimdir.
• Ne yaptığınızı tam olarak bilmiyorsanız, paylaşılan bir dalda git push --force kullanmaktan kaçının. Herkesin geçmişini yeniden yazar.

Emin değilseniz şunu sorun:

Son değişiklik giriş sayfasını bozdu. Bir önceki commit'e kıyasla hangi dosyaları değiştirdiğini göster ve her değişikliğin ne yaptığını açıkla. Henüz hiçbir şeyi değiştirme.

Adım 6: İstem yazmadan önce çekin

Bir geliştirici ya da başka bir araç GitHub'daki kodu değiştirirse, AI oluşturucu siz bu değişiklikleri çekene kadar bunu bilmez. Eski kod üzerinde istem yazmak çakışmalara ve kayıp işe yol açar.

• Her oturumun başında çekin.
• Kimin neyi düzenlediğini belirleyin ve iki tarafın aynı anda aynı dosyaları düzenlemesinden kaçının.
• Birleştirme çakışması (aynı satırlara iki değişiklik) alırsanız, çakışmayı çözmesini ve seçimini açıklamasını geliştiriciden ya da AI'dan isteyin.

Örnek istemler

Başlamadan önce: son oturumumdan bu yana depoda neler değişti? Commit'leri özetle.

Sonraki değişikliği tek başına yap: her faturaya bir "Çoğalt" düğmesi ekle. Başka hiçbir şeyi değiştirme, böylece bunu ayrı bir commit olarak kaydedebilirim.

Git'te, geçmiş commit'ler dahil, hiçbir API anahtarının, şifrenin ya da .env dosyasının izlenmediğini kontrol et. Yalnızca dosya adlarını bildir, değerlerini değil.

Sık yapılan hatalar

• Gizli bilgileri commit etmek. Bir anahtar Git geçmişine girdiğinde, dosyayı silseniz bile açığa çıkmış olur. Anahtarı yenileyin.
• Haftada bir dev commit. Tüm değişiklikleri geri almadan tek birini geri alamazsınız.
• "güncelleme" gibi mesajlar. Neyin bozulduğunu bulmak için geçmiş işe yaramaz hale gelir.
• Eski kod üzerinde istem yazmak. Başkası düzenliyorsa önce çekin.
• Bir hatayı düzeltmek için force push yapmak. Başkalarının işini silebilir. Bunun yerine revert kullanın.
• node_modules commit etmek. Çok büyüktür ve zaten kilit dosyasından yeniden oluşturulur.

Kontrol listesi

• Proje özel bir depoya bağlı.
• .gitignore dosyası .env, node_modules, derleme çıktısını ve gizli bilgileri dışarıda tutuyor.
• Çalışan her değişiklikten sonra commit atıyorum.
• Commit mesajları neyin değiştiğini tek satırda anlatıyor.
• Büyük ya da riskli değişiklikler bir dalda yapılıp inceleniyor.
• Başka biri kodu düzenliyorsa istem yazmadan önce çekiyorum.
• Kontrol noktalarıyla ya da git revert ile geri alıyorum, force push ile değil.
• Bir kez bile commit edilmiş her anahtar yenilendi.

Mythex'te Git

Mythex, her başarılı agent turundan sonra bir git kontrol noktası kaydeder ve Bu noktaya geri dön seçeneği projeyi o noktaya geri alır; bu, 5. adımda anlatılan oluşturucu tarafındaki geri almadır. Ayrıntılar için Yinelemeli çalışma, yeniden kurmadan sayfasına bakın.

Pro planda GitHub senkronizasyonu, proje ayarlarından bir depoyu bağlar, böylece ona karşı gönderme ve çekme yapabilirsiniz. Dışa aktar seçeneği ise gizli bilgiler ve node_modules hariç projeyi indirir. Ayrıntılar için GitHub, dışa aktarma ve içe aktarma sayfasına bakın. Projeyi bir geliştiriciye vermeden önce GitHub'ı bağlamak devir teslimi çok kolaylaştırır; bkz. AI ile yapılmış uygulamada geliştiriciyle nasıl çalışılır ve AI ile yapılmış uygulamayı nasıl dışa aktarıp kendi sunucunuzda çalıştırırsınız.

Sorular