Bir yanda yeni bir özellik geliştirirken diğer yanda acil bir hatayı çözmek gerektiğinde, aynı klasörde çalışmak dikkati dağıtabilir. Dosyalar, geçici düzenlemeler ve çalışan geliştirme sunucusu birbirine karışır. Git worktree, aynı deponun farklı çalışma kopyalarıyla ilerlemeyi sağlar. Codex'in worktree desteği de bağımsız sohbetleri ayrı çalışma alanlarında yürütmek için kullanılabilir. Yine de ayrı klasör, bütün kaynakların otomatik olarak ayrıldığı anlamına gelmez.
Başlangıç noktasını açıkça seçin
Yeni görev hangi kod durumundan başlamalı? Son yayınlanan sürümden açılan bir hata düzeltmesi ile devam eden özellik dalını temel alan bir tasarım işi aynı başlangıca sahip değildir. Codex'e görev verirken dalı veya revizyonu belirtin; mevcut kaydedilmemiş değişikliklerin dahil edilmesini bekliyorsanız bunun nasıl aktarılacağını doğrulayın.
Örnek durumumuzda ana klasörde abonelik sayfası değişiyor, ayrı worktree'de ise e-posta doğrulama hatası gideriliyor. Doğrulama işi henüz yayınlanmamış abonelik koduna bağlı olmamalıysa başlangıç noktası buna göre seçilmelidir. Bu karar, daha sonra gereksiz kodun acil düzeltmeye taşınmasını önler.
Klasör kadar çalışma ortamını da ayırın
Worktree dosyaları ayırır; veritabanı, port, dış servis hesabı veya yükleme dizini aynı kalabilir. İki geliştirme sunucusunun aynı portu kullanması küçük bir çakışmadır. İki görevin aynı test verisini değiştirmesi ise hatalı sonuçlara neden olabilir. Her çalışma alanı için gereken ortam değişkenlerini, bağımlılık kurulumunu ve kullanılan test verisini gözden geçirin.
Aşağıdaki görev metni bu hazırlığı somutlaştırır:
E-posta doğrulama hatasını ayrı worktree'de çöz. Başlangıç revizyonunu raporla. Ana çalışma klasöründeki abonelik değişikliklerine dokunma. Önce bağımlılık ve test ortamının hazır olduğunu doğrula; ortak veritabanına yazacak bir işlem gerekirse etkisini belirt. Hata düzeltmesini ilgili dosyalarla sınırla ve yeniden üretim sonucunu kaydet.
Buradaki ek sınırlar, worktree özelliğinin yerine geçmez; ekibin bu örnekte ihtiyaç duyduğu çalışma düzenini tarif eder.
Sonucu birleştirmeden önce farkı inceleyin
Görev tamamlandığında yalnızca “testler geçti” cümlesiyle ilerlemeyin. Değişen dosyaları, başlangıca göre farkı ve beklenmedik üretilmiş dosyaları inceleyin. Paket kilidi, yerel yapılandırma veya geçici ekran görüntüsü yanlışlıkla değişikliğe karışmış olabilir. Bunları ayırmak incelemeyi kolaylaştırır.
Ardından düzeltmeyi hedef dala taşıma biçimini seçin. Birleştirme sonrası iki dalın birlikte çalıştığı durum farklıdır; özellikle ortak bir yardımcı fonksiyon değiştiyse ilgili kısa kontrolü tekrar yapmak gerekir. Her worktree'nin ayrı ayrı başarılı olması, birleşen sonucun doğruluğunu tek başına kanıtlamaz.
Çalışma alanını işi bitince düzenleyin
Sonuç korunduğunda worktree'nin hâlâ gerekli olup olmadığını değerlendirin. Kullanıcıya ait kaydedilmemiş dosyaları kontrol etmeden klasörü silmeyin. Hangi dalda hangi işin kaldığını anlaşılır isimlerle kaydetmek, bir hafta sonra aynı göreve dönmeyi kolaylaştırır.
Bu örnekte başarılı sonuç, ana klasördeki abonelik çalışmasının kesilmemesi ve e-posta düzeltmesinin küçük bir değişiklik olarak incelenebilmesidir. İşleri ayırmanın değeri klasör sayısında değil, her görevin başlangıcının, ortamının ve çıktısının anlaşılır kalmasındadır.
Ortak kaynaklar için küçük bir not yeterlidir: Hangi port kullanılıyor, hangi veritabanına bağlanılıyor ve testler geçici dosyayı nereye yazıyor? Bu notu güncel tutmak, iki bağımsız işin aynı ortamı farklı varsayımlarla kullanmasını önler. Özellikle arka planda devam eden süreçleri, çalışma alanı tamamlandığında kapatmayı da işin son adımına ekleyin.
Resmî kaynak: OpenAI — Git worktrees.
