Usi GitHub senza sapere davvero cosa stai facendo?
Andare alla cieca porta solo a fare danni.
Su GitHub ci sono solo tre pulsanti verdi.
E c'è un solo punto da controllare prima di premerli.
In questo articolo ti mostro ogni singolo punto da guardare e cliccare sullo schermo di GitHub, evidenziato con dei riquadri rossi.
Connetti, invia, controlla il diff, fai il merge e annulla.
Attraverseremo tutto questo ciclo usando 10 screenshot reali.
A digitare ci pensa l'AI.
Tu devi solo guardare e premere.
Spiegherò i termini più ostici in modo semplice man mano che li incontriamo.
※ Le schermate e le specifiche di GitHub presenti in questo articolo sono state verificate a ottobre 2026. L'interfaccia potrebbe subire modifiche.
Capitolo 1: Connettersi a GitHub | Creare un repository e caricare i record locali
L'interfaccia di GitHub è in inglese.
Ma i punti da cliccare sono sempre gli stessi.
I riquadri rossi nelle immagini ti mostrano dove guardare e dove premere.
In questo capitolo c'è un solo pulsante verde da premere.
Per prima cosa, crea un repository.
Un repository è come un armadietto in cui archivi online i tuoi record Git.
Ho già spiegato cosa si mette dentro questo armadietto e quattro termini chiave nel mio post precedente.
【Con diagrammi】Git spiegato per studenti delle scuole medie
https://x.com/dan_pro_man/status/2107224533099069671?s=20
Anche se non lo hai letto, puoi completare l'intero ciclo seguendo solo questo articolo.
Accedi a GitHub e seleziona "New repository" dall'icona "+" in alto a destra.
Puoi anche aprire direttamente https://github.com/new per arrivare alla stessa schermata.
L'unica cosa che devi inserire è un nome.
Scrivi un nome alfanumerico nel campo "Repository name".
"git-practice" va benissimo.
Seleziona "Private" sotto "Choose visibility".
Significa che non sarà pubblico.
Lascia disattivato per ora l'interruttore "Add README".
Se hai già dei record locali, è molto più facile connettersi partendo da un repository vuoto.
Premi il pulsante verde "Create repository" in basso.
La schermata che appare subito dopo è la parte più importante di questo capitolo.
Verso il fondo trovi un titolo: "…or push an existing repository from the command line".
Le tre righe qui sotto sono i comandi che useremo oggi.
Le sette righe sopra servono a chi non ha ancora record locali, quindi puoi ignorarle.
Ecco cosa significano quelle tre righe:
Riga 1: Comunica al tuo record locale l'indirizzo di questo armadietto.
Riga 2: Allinea il nome del branch principale a "main".
Riga 3: Archivia il branch main nell'armadietto.
Copia l'indirizzo (riquadro rosso) da questa schermata e invialo all'AI in una sola riga.
1Carica i record presenti in questa cartella su https://github.com/nome-account/git-practice
Claude Code digiterà da solo quelle tre righe.
Claude Code è un'AI che esegue operazioni sul tuo computer seguendo le tue istruzioni.
Nel mio manuale operativo pretendo una conferma prima di ogni push.
Il push è l'operazione con cui salvi i record locali nell'armadietto.
Quindi, a questo punto si ferma.
Rispondi "Yes", poi aggiorna la pagina del browser.
Al posto dei tre comandi, ora vedrai i tuoi file locali allineati. Accanto c'è il messaggio di commit.
Questo è il segnale che sei "connesso".
Ora voglio farti notare una cosa.
La scritta "main" sopra l'elenco dei file.
Indica quale segnalibro stai visualizzando in quel momento dentro l'armadietto.
Un segnalibro è un branch.
Segna in quale colonna stai impilando i record.
Da ora in poi, non toccare mai direttamente questo "main".
All'inizio nemmeno io ci facevo molto caso.
Lavoravo su main e perdevo un sacco di tempo a capire come tornare indietro.
Quando le connessioni falliscono, di solito è colpa dell'indirizzo.
Manca il ".git" finale.
Il nome dell'account è scritto male.
Se vedi "not found", copia di nuovo l'indirizzo dall'immagine ②.
A questo punto, i tuoi record locali sono connessi a GitHub. Il prossimo passo è il ciclo quotidiano di merge tramite Pull Request.
**
Capitolo 2: Fare il merge tramite Pull Request | Invia il lavoro dell'AI, controlla il diff e premi
Da qui inizia il ciclo quotidiano.
Una Pull Request è una richiesta che dice: "Per favore, integra queste modifiche".
In questo capitolo ci sono tre pulsanti verdi da premere.
A digitare ci pensa l'AI.
Il tuo unico compito è guardare e premere.
Per prima cosa, invia una riga all'AI.
1Crea un nuovo branch, aggiungi 3 righe di istruzioni d'uso al README, fai il commit e carica su GitHub
Il README è il primo file in cui scrivi la descrizione del repository.
Claude Code crea un branch.
Modifica il file e fa il commit.
Infine, si ferma prima del push e ti chiede conferma.
Rispondi "Yes", poi apri l'armadietto nel browser.
In alto compare un banner giallo.
Ti avvisa: "Ho appena salvato questo branch".
Premi il pulsante verde "Compare & pull request" sulla destra.
Questa è la 'Richiesta'.
Come consegnare la brutta copia del quaderno all'insegnante.
Fare la richiesta non copia nulla nella versione definitiva.
La copia avviene solo dopo la revisione.
Nella schermata della richiesta ci sono tre punti da controllare.
Primo: la freccia in cima.
"base: main" e "compare: work-branch"
Mostra da dove a dove verrà fatto il merge.
Ti basta confermare che a sinistra ci sia main.
Secondo: il titolo in "Add a title".
Se lo genera l'AI, includerà un riepilogo delle modifiche.
Se lo invii manualmente, il messaggio di commit sarà già compilato.
Se procedi a mano, scrivi in una riga "cosa è stato fatto".
Terzo: il pulsante verde "Create pull request".
Premendolo accetti la richiesta.
Dopo l'invio serve l'intervento umano.
In alto compaiono quattro schede.
Guarda solo l'ultima a destra, "Files changed".
Significa "file modificati".
Le righe verdi sono quelle aggiunte.
Le righe rosse sono quelle eliminate.
Questo è il diff.
Se le 3 righe che hai richiesto sono verdi, è tutto ok.
Nell'immagine di esempio sono stati aggiunti anche titoli e righe vuote, arrivando a 6 righe verdi.
Se ci sono righe rosse che non avevi chiesto, non fare il merge.
Nell'esempio c'è 1 riga rossa.
È sparita una riga di note da "Items placed".
Se non l'avevi richiesto, fermati qui.
Chiedi all'AI: "Perché hai cancellato questa riga rossa?"
Questi sono i 30 secondi più critici quando deleghi il lavoro all'AI.
Ai tempi in cui bastava vedere le notifiche di revisione per farmi venire il mal di stomaco, premevo senza controllare.
Ora, invece, conto prima le righe rosse.
Se ce n'è anche solo una non richiesta, mi fermo.
Se il diff non presenta problemi, torna su "Conversation".
Verso il basso trovi il pulsante verde "Merge pull request".
Se sopra c'è scritto "No conflicts with base branch", puoi procedere direttamente al merge.
Premendolo, la scritta diventa "Confirm merge".
Premilo di nuovo.
Ora i record del branch di lavoro sono integrati in main.
Il colore diventa viola e appare la scritta "Merged".
Sotto compare un riquadro con "Pull request successfully merged and closed".
Alla sua destra c'è "Delete branch".
Premilo pure senza paura.
Sparirà solo il "segnalibro" del branch di lavoro dentro l'armadietto.
Poiché i record sono già stati uniti a main, non perdi nulla.
Infine, aggiorna il tuo ambiente locale.
Scrivi all'AI: "Passa a main e scarica le ultime modifiche da GitHub".
Così hai completato un ciclo.
Inizia la prossima attività da un nuovo branch.
Non lavorare mai su main.
A questo punto hai concluso il ciclo di invio, controllo del diff e merge. Ora parliamo di Revert, il pulsante per annullare gli errori dopo il merge.
**
Capitolo 3: Il Revert | Annulla gli errori dopo il merge con un solo pulsante
A volte ti accorgi degli errori solo dopo aver fatto il merge.
In Git, "annulli" i record salvati senza cancellarli.
Sull'interfaccia di GitHub c'è un pulsante apposta.
Si chiama "Revert".
Riapri la Pull Request che hai appena integrato.
Troverai una riga con scritto "merged commit … into main".
All'estrema destra di quella riga c'è "Revert".
Cosa succede se lo premi?
I record non vengono cancellati.
Viene creata una nuova Pull Request con le modifiche opposte.
Secondo la documentazione ufficiale, l'annullamento effettivo avviene quando integri questa nuova Pull Request.
Quindi, il revert segue lo stesso ciclo del Capitolo 2.
Controlla il diff e premi il pulsante verde.
Invece di cancellare, viene aggiunto un record che dice "reverted" (annullato).
Se vuoi chiederlo all'AI, scrivi: "Annulla la Pull Request che ho appena integrato".
Claude Code fa la stessa identica cosa usando git revert.
C'è un'altra schermata in cui potresti imbatterti.
"This branch has conflicts that must be resolved".
Questo è un conflitto.
Si verifica quando la stessa riga è stata modificata in modo diverso su main e sul branch di lavoro.
Il pulsante verde diventa grigio e non può essere premuto.
Non cercare di risolverlo dall'interfaccia; invia piuttosto questa riga all'AI.
1Scarica main e mostrami entrambe le versioni delle parti in conflitto
Sarai tu a decidere quale mantenere.
Quando l'AI sistema il problema e ricarica tutto, il pulsante verde tornerà cliccabile.
I conflitti non sono fallimenti.
Ti stanno semplicemente dicendo che la stessa riga è stata modificata due volte.
Infine, una cosa che non appare sullo schermo.
Le chiavi.
I file che contengono password o API key non devono mai essere caricati su GitHub.
Anche se usi il Revert, una volta che una chiave è stata caricata va considerata compromessa e deve essere rigenerata.
Prima di caricare, scrivi all'AI: "Escludi .env dai record".
Nel mio ambiente di lavoro scrivo le configurazioni AWS in file di testo e seguo esattamente questo ciclo.
Le configurazioni integrate senza controllare i diff finiscono dritte in produzione.
Per questo non delego all'AI quei 30 secondi critici prima di premere il pulsante.
Tutti i pulsanti sullo schermo li premono gli esseri umani.
Anche se continuo ad ampliare ciò che affido all'AI, questa regola resta immutata.
A questo punto, il ciclo completo di connessione, invio, merge e revert è concluso.
Infine, ti metto a disposizione del materiale pronto all'uso.
Ho messo nero su bianco tutti i passaggi per completare un ciclo sull'interfaccia di GitHub.
Ho raccolto le schermate e i prompt di questo articolo in formati pronti all'uso.
- Poster con la traduzione delle schermate di GitHub (9 schermate, 69 termini)
- Mappa di recupero per quando l'AI fa danni (6 scenari)
- 7 prompt per un ciclo completo
- Checklist pre-merge (8 voci)
Il tutto consegnato insieme in un libretto PDF di 15 pagine.
Solo con questi materiali puoi iniziare a completare i cicli già da oggi.
Per riceverli, ti basta entrare nell'Open Chat qui sotto.
Segui le istruzioni dopo essere entrato, invia "Submit" e lo riceverai in automatico.
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
Riepilogo: completa un solo ciclo oggi
Non mettere mai il lavoro dell'AI direttamente su main.
Invia da un branch di lavoro, controlla il diff e premi i pulsanti verdi.
In un ciclo ci sono tre pulsanti verdi da premere.
Il giorno in cui ho premuto Revert da solo per la prima volta, ho capito che i record non vengono cancellati.
Da quel momento ho smesso di avere paura di toccare le cose.
Non devi fare tutto in una volta.
Oggi c'è una sola cosa da fare.
Apri il repository creato nel Capitolo 1 e invia una riga all'AI.
Crea un nuovo branch, aggiungi 1 riga al README e carica su GitHub
Quando compare il banner giallo, premi il pulsante verde e apri "Files changed".
Se c'è solo una riga verde, è tutto ok.
Guarda quella riga con i tuoi occhi prima di fare il merge.
Questo è il primo passo per ampliare ciò che puoi delegare all'AI.
Per gli ingegneri over 30, vincere non significa produrre di più, ma progettare meglio.
Invece di reimparare a usare gli strumenti ogni volta che si aggiornano, è molto più veloce definire dove mettere i paletti.
AWS e l'AI evolvono rapidamente.
Leggere i log di chi fa test sul campo è più veloce che cercare di stare al passo da soli.
Nella mia pratica quotidiana tra AI e ingegneria lascio traccia non solo dei successi, ma anche degli errori e delle esclusioni.
Seguimi per non perderti i prossimi spunti! @dan_pro_man
